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.

Should we stop here or should we go for a proper command-line parser?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering