digitalmars.D.bugs - [Issue 11149] New: Runtime.args no longer available in static constructors.
- d-bugmail puremagic.com (33/33) Sep 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (14/14) Oct 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/10) Oct 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (12/12) Oct 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (7/8) Oct 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/10) Oct 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (16/16) Oct 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (12/14) Oct 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (15/18) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (21/29) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (18/22) Oct 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (8/17) Oct 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (6/6) Oct 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (7/8) Oct 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (11/12) Oct 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/13) Oct 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (14/19) Oct 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/10) Oct 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/10) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (14/14) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/12) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (8/12) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (7/7) Oct 26 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (8/8) Oct 26 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/12) Oct 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (7/8) Oct 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (10/10) Oct 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
- d-bugmail puremagic.com (9/9) Oct 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11149
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Summary: Runtime.args no longer available in static constructors. Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: druntime AssignedTo: nobody puremagic.com ReportedBy: mike-wey planet.nl With git head/2.064 core.runtime.Runtime.args always returns null when called from a static constructor, with 2.063 it used to return the commandline args. Calling it from main works in both versions. ---- import core.runtime; string[] test; shared static this() { test = Runtime.args; } void main() { assert(test !is null); } ---- The assert fails with git head/2.064. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 04:36:46 PDT --- Any platform details? I can't reproduce this on Win7 (using -m32) with these recent commits: dmd: e0a201bbf80fb7bfbc7e5caf2c29921c3bddf5e3 druntime: 12d535030de97835b4c2fb96d079942d93ea708e phobos: d744bec6d4500d6cb6f43011beefc7765dd0e5ce -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Mike Wey <mike-wey planet.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |Linux Linux, both 64 and 32 bits. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |WORKSFORME 02:17:05 PDT --- This is working for me with dmd 2.064 head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 05:36:04 PDT ---This is working for me with dmd 2.064 head.On Linux? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Martin Nowak <code dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code dawg.eu *** Issue 11191 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Martin Nowak <code dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | This is a regression caused by moving the module initialization into C's .ctor/.dtor sections. Not sure how to resolve this right now. BTW, I don't that adding args/cArgs was a good idea in the first place. They provide global access to mutable data but the exact semantics remain unclear, e.g. how is mutating args reflected in main's args and vice versa. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 10:20:03 PDT ---BTW, I don't that adding args/cArgs was a good idea in the first place.Some libraries require the C arguments during initialization routines. If you try to initialize such a library in a module constructor then core.runtime is the only way of getting to the main() arguments.how is mutating args reflected in main's args and vice versa.It's not reflected since a copy is made in _d_run_main. But I guess this should be documented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Martin Nowak <code dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody puremagic.com |code dawg.euIt's not reflected since a copy is made in _d_run_main. But I guess this should be documented.The arguments are not copied.This is a regression caused by moving the module initialization into C's.ctor/.dtor sections. Other than poking around in glibc's internals we can only resolve this issue by delaying D's initialization until C's main again. I'll look into this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 07:26:55 PDT ---I'm not seeing that: ----- import core.runtime; import std.stdio; import std.string; void main(char[][] args) { auto c_args = Runtime.cArgs; printf("%s\n", c_args.argv[0]); c_args.argv[0] = cast(char*)("foobar\0".dup.ptr); printf("%s\n", c_args.argv[0]); writeln(args[0]); } ----- $ rdmd test.dIt's not reflected since a copy is made in _d_run_main. But I guess this should be documented.The arguments are not copied.C:\Users\ADMINI~1\AppData\Local\Temp\.rdmd\rdmd-test.d-E4AFE2A9EC3418A8D53133284F27D58A\test.exe foobar C:\Users\ADMINI~1\AppData\Local\Temp\.rdmd\rdmd-test.d-E4AFE2A9EC3418A8D53133284F27D58A\test.exe-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149Yes, the C args are copied to the D args. But the C args themselves are not copied. If you run a custom C main this might cause problems but that is a programming error we don't need to fix. Another problem is when you have a C program that links against a D library, we don't have access to main's arguments here. Same issue for shared libraries where providing access to main arguments hardly makes sense. I'm a bit annoyed by this issue because it's so obviously wrong to provide global access to main's arguments before main gets called. If someone wanted global access they could just copy the arguments into a global variable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------The arguments are not copied.I'm not seeing that:
Oct 17 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 06:58:53 PDT ---But C libraries probably already expect this behavior. That's the only thing cArgs is for really, to interface with those C libs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Yes, the C args are copied to the D args. But the C args themselves are not copied. If you run a custom C main this might cause problems but that is a programming error we don't need to fix.The arguments are not copied.I'm not seeing that:
Oct 18 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 14:25:36 PDT --- Martin, what do we do about this one? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 22 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149Martin, what do we do about this one?I don't know yet but try to find a solution as soon as I have time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Jacob Carlborg <doob me.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |doob me.comI don't know yet but try to find a solution as soon as I have time.Could you read /proc/self/cmdline ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149Thanks for the idea Jacob. It would solve the regression but it's not portable. So once we port the shared library bits to FreeBSD/OSX it will break on those platforms. NB: Shared libraries were the reason to move the init/fini calls. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I don't know yet but try to find a solution as soon as I have time.Could you read /proc/self/cmdline ?
Oct 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149Thanks for the idea Jacob. It would solve the regression but it's not portable. So once we port the shared library bits to FreeBSD/OSX it will break on those platforms. NB: Shared libraries were the reason to move the init/fini calls.None of this low level stuff is portable. FreeBSD: using sysctl with KERN_PROC_ARGS looks like it would to the trick. See: http://www.freebsd.org/cgi/man.cgi?query=sysctl&sektion=3&apropos=0&manpath=FreeBSD+9.2-RELEASE https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L1650 Mac OS X: _NSGetArgv and _NSGetArgc. See /usr/include/crt_externs.h. Windows (if needed): GetCommandLine. See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683156.aspx -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 9999 <mailnew4ster gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mailnew4ster gmail.com For Windows there's also CommandLineToArgvW. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Thanks, that should work indeed. There is at least another regression due to the implicit init/fini of druntime (bug 11309). So I'll fix this and the other bug by make the initialization of shared D libraries explicit. There are a few more reasons for this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 BWT, I forgot to mention this. If I recall correctly,_NSGetArgv and _NSGetArgc are private functions. That means, they are not allowed in sandboxed applications, that is, applications in App Store, both on Mac OS X and iOS. I don't know if this is something we would like to care about. On the other hand we already use _NSGetEnviron in std.process. But all of these are mentioned in the documentation of NSApplicationMain, here: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Miscellaneous/AppKit_Functions/Reference/reference.html#//apple_ref/c/func/NSApplicationMain Question, how is the runtime initialized now? I mean, is it initialized in a shared module constructor? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149Question, how is the runtime initialized now? I mean, is it initialized in a shared module constructor?At least on linux it is done from .ctor/.dtor functions that call _d_dso_registry. This is the similar to __attribute__((constructor))/__attribute__((destructor)) functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149At least on linux it is done from .ctor/.dtor functions that call _d_dso_registry. This is the similar to __attribute__((constructor))/__attribute__((destructor)) functions.How does the compiler make sure that the .ctor that initializes the runtime is run before any user shared module constructors? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 13:41:20 PDT --- I'd like to get 2.064 release finalized. That means this regression needs to be fixed, or deferred. What do you guys think? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 26 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Another idea that could work is to not use .ctor for the shared module constructors, as before. Then have a single .ctor that initializes the runtime. The shared module constructors would be run from C main/rt_init as before. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 26 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149I'd like to get 2.064 release finalized. That means this regression needs to be fixed, or deferred. What do you guys think?We can't defer it, because it has too much impact IMO. For example vibe.d uses Runtime.args to process command line arguments. There are probably more tools taking this approach all of which would break. I filed the underlying issue as bug 11378 and currently work on a fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 29 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 13:19:10 PDT ---I filed the underlying issue as bug 11378 and currently work on a fix.Thank you! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 29 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/d3c89cf1894aefa884303344a18436841eae0744 fix Issue 11149 - Runtime.args no longer available in static constructor - This got fixed by reverting the order of initialization. - Add unittest -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 30 2013