Date: Sun, 13 Mar 2022 23:37:42 -0400
On 3/13/22 11:23 PM, Thiago Macieira via Std-Discussion wrote:
> On Sunday, 13 March 2022 16:00:07 PDT Jason McKesson via Std-Discussion wrote:
>> Considering that we can have arbitrary numbers of constructors that
>> execute arbitrary amounts of code pre-main, I can't imagine how a few
>> strlen calls would be a legitimate problem. It would be opt-in anyway,
>> so it's not like you're paying for it if you don't want it.
> Indeed, but those are choices. You don't have to use those if you don't want
> to. Moreover, none of those would have a runtime complexity dependence on the
> command-line (there's a way to do that with platform-specific extensions, but
> again it's a choice and extremely an rare occurrence).
>
> The worst-case scenario are 65536 1-byte arguments on Linux. On a 64-bit
> system, that's an array occupying 1 MB of the stack, or a whole 12.5% of the
> standard stack space for the main thread. This is in addition to the 0.5 MB
> that argv has already occupied, plus the 128 kB of the characters themselves,
> but at least the time complexity for those is accounted to the parent process.
>
>>> And then there's Windows.
>> That's a far more pernicious issue, one that suggests that there
>> simply be a way to query command line arguments, rather than having
>> them fed through main.
> Indeed, which is where that platform-specific way of getting the command-line
> comes in handy. As far as I can tell, this can be done by the C++ runtime
> without the C runtime's help in all the major platforms, if required.
>
> It would be an initialise-on-first-use type of scenario, which makes sure we
> don't violate "don't pay for what you don't need". I'd design this on top of
> std::fs:path_view or equivalent, so you can recover both the original native
> content as well as an Unicode equivalent, plus the ability to go directly to a
> file name, which command-line arguments usually but not always are.
Similar thoughts have previously been captured in the following SG16 issue:
* https://github.com/sg16-unicode/sg16/issues/66#issuecomment-765689413
>
> Should we stop here or should we go for a proper command-line parser?
One step at a time :)
Tom.
> On Sunday, 13 March 2022 16:00:07 PDT Jason McKesson via Std-Discussion wrote:
>> Considering that we can have arbitrary numbers of constructors that
>> execute arbitrary amounts of code pre-main, I can't imagine how a few
>> strlen calls would be a legitimate problem. It would be opt-in anyway,
>> so it's not like you're paying for it if you don't want it.
> Indeed, but those are choices. You don't have to use those if you don't want
> to. Moreover, none of those would have a runtime complexity dependence on the
> command-line (there's a way to do that with platform-specific extensions, but
> again it's a choice and extremely an rare occurrence).
>
> The worst-case scenario are 65536 1-byte arguments on Linux. On a 64-bit
> system, that's an array occupying 1 MB of the stack, or a whole 12.5% of the
> standard stack space for the main thread. This is in addition to the 0.5 MB
> that argv has already occupied, plus the 128 kB of the characters themselves,
> but at least the time complexity for those is accounted to the parent process.
>
>>> And then there's Windows.
>> That's a far more pernicious issue, one that suggests that there
>> simply be a way to query command line arguments, rather than having
>> them fed through main.
> Indeed, which is where that platform-specific way of getting the command-line
> comes in handy. As far as I can tell, this can be done by the C++ runtime
> without the C runtime's help in all the major platforms, if required.
>
> It would be an initialise-on-first-use type of scenario, which makes sure we
> don't violate "don't pay for what you don't need". I'd design this on top of
> std::fs:path_view or equivalent, so you can recover both the original native
> content as well as an Unicode equivalent, plus the ability to go directly to a
> file name, which command-line arguments usually but not always are.
Similar thoughts have previously been captured in the following SG16 issue:
* https://github.com/sg16-unicode/sg16/issues/66#issuecomment-765689413
>
> Should we stop here or should we go for a proper command-line parser?
One step at a time :)
Tom.
Received on 2022-03-14 03:37:43