Date: Tue, 10 Aug 2021 09:39:44 -0700
On Monday, 9 August 2021 12:33:52 PDT Charlie Barto via SG16 wrote:
> I think exposing the global could work fine for shared libraries. On linux
> it should be no problem because the runtime shouldn't have to allocate any
> memory or anything (i.e. there's no actual initialization code that needs
> to run for the global). On Windows there could be some dll related problems
> but it still seems implementable to me.
On Windows, the command-line is already available as a global, albeit with a
platform-specific API (GetCommandLineW). This C++ std API could do the
allocation on first use, if necessary.
> Also correction to my comment on rust's env::args mechanism, they actually
> do kill the program upon seeing any invalid arguments, their env::os_args
> mechanism gives you "WTF-8" (on windows) or a byte-string (on unix), and
> won't kill the process.
But they also don't have a legacy to deal with. Not at all our situation here.
> I think exposing the global could work fine for shared libraries. On linux
> it should be no problem because the runtime shouldn't have to allocate any
> memory or anything (i.e. there's no actual initialization code that needs
> to run for the global). On Windows there could be some dll related problems
> but it still seems implementable to me.
On Windows, the command-line is already available as a global, albeit with a
platform-specific API (GetCommandLineW). This C++ std API could do the
allocation on first use, if necessary.
> Also correction to my comment on rust's env::args mechanism, they actually
> do kill the program upon seeing any invalid arguments, their env::os_args
> mechanism gives you "WTF-8" (on windows) or a byte-string (on unix), and
> won't kill the process.
But they also don't have a legacy to deal with. Not at all our situation here.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2021-08-10 11:39:55