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:
Should we stop here or should we go for a proper command-line parser?
One step at a time :)
Tom.