October 18, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #10 from Martin Nowak <code@dawg.eu> 2013-10-17 22:07:20 PDT ---
(In reply to comment #9)
> > The arguments are not copied.
> 
> I'm not seeing that:
> 
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.

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: -------
October 18, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #11 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-18 06:58:53 PDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > > The arguments are not copied.
> > 
> > I'm not seeing that:
> > 
> 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.

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: -------
October 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #12 from Walter Bright <bugzilla@digitalmars.com> 2013-10-22 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: -------
October 23, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #13 from Martin Nowak <code@dawg.eu> 2013-10-23 04:21:48 PDT ---
(In reply to comment #12)
> Martin, 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: -------
October 23, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #14 from Jacob Carlborg <doob@me.com> 2013-10-23 04:56:19 PDT ---
(In reply to comment #13)

> I 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: -------
October 23, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #15 from Martin Nowak <code@dawg.eu> 2013-10-23 08:10:32 PDT ---
(In reply to comment #14)
> > I don't know yet but try to find a solution as soon as I have time.
> 
> Could you read /proc/self/cmdline ?

Thanks 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: -------
October 23, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #16 from Jacob Carlborg <doob@me.com> 2013-10-23 08:26:27 PDT ---
(In reply to comment #15)

> Thanks 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: -------
October 23, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149


9999 <mailnew4ster@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mailnew4ster@gmail.com


--- Comment #17 from 9999 <mailnew4ster@gmail.com> 2013-10-23 08:32:54 PDT ---
For Windows there's also CommandLineToArgvW.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 25, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #18 from Martin Nowak <code@dawg.eu> 2013-10-25 08:44:13 PDT ---
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: -------
October 25, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11149



--- Comment #19 from Jacob Carlborg <doob@me.com> 2013-10-25 08:59:00 PDT ---
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: -------