Re: argv

[Enno Borgsteede <ennoborg gmail com>]

Andrew,
> On 4/16/2016 at 1:47 PM, Enno Borgsteede <ennoborg gmail com> wrote:
>
> > > 1) Argc and argv are initially processed only by the OS, and never by the
> > > linker or GTK or any compiler until after main() is called. Nothing you can
> do
> > > with the linker, GTK, or the compiler can change that fact.
> > Not true. The program arguments are supplied by the OS, but not
> > necessarily as argc and argv.
> That's funny! What are they supplied as? argz and argf?
I have no idea. It's up to the OS, and reading your initial message, and 
the latest by Bill Kelly, I think it's safe to assume that Windows 
doesn't supply anything arg like when it starts an EXE.

> > In a C program, they are prepared by the
> > init part of the run time library, which is linked against the main
> > program. That init part makes sure that argc and argv etc. are passed in
> > a format that main understands. Check
> > http://stackoverflow.com/questions/3469955/in-c-how-is-the-main-method-initially-called
> Notice how there is no accepted answer to that question? There is no such
> thing as a "C program". There are programs that are written in C but there are
> no C programs.
I know what I read, and I have debugged loads of C programs at times 
when source level debuggers were too memory hungry to run on the 
available hardware. The experience that I gained then tells me that the 
answers on stackoverflow are close enough to illustrate that argc and 
argv are prepared by some OS dependent startup code. And if you don't 
have that code in your program, there is no argc and argv in registers, 
on the stack, or anywhere else where you think it is.

And in my language a C program is short for a program written in C.
> In reality, the operating system is what parses the command line only for the
> number of arguments and the command line itself ... nothing more and nothing
> less.
I think it's safer not to assume anything about the OS. It's obvious 
that in needs to parse a command line in such a way that it knows what 
built in command or executable program needs to be started, but any 
assumption going further than that is at your own risk.

> > and http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
> That's interesting but I'm not using Linux, I'm using GTK on a Win32 system.
> And if you had actually read that article, you would know the only thing it
> says about argc and argv is that it pushes them onto the stack ... nothing
> more and nothing less.
I read that, and I know that it's about Linux, and you're building a 
Win32 program. But the overall scheme is the same on Windows, meaning 
that the code called on entry, i.e. not main, processes whatever 
available in the process context to create argc and argv values to be 
used by main.

And if you don't have that code, which in this context can be linked 
from the C runtime library, you can not count on argc and argv being 
available. They happen to be there in Linux, because the Linux exec 
variants put them there, but as far as I know, that is not the case for 
Windows (see Bill Kelly's reply).

> A calling convention is a specification of how a callee passes 
> parameters to a caller, and whether the callee or caller clean up the 
> stack afterwards. It is not a property of the compiler or language, it 
> is only a property of an API or a DLL. 
Rubbish. I've debugged enough code to know that there are differences in 
conventions between compilers and languages. For instance in C, strings 
are much different from strings in Pascal, so the way you retrieve them 
in a procedure or function written in assembler is highly different.

This is true for compilers and CPU architectures too, meaning that one C 
compiler may push everything on the stack, where another uses CPU 
registers until they run out, and available registers depend on CPU 
architecture. Moreover, with proper optimization, a call to a C function 
may not be compiled into a real call at all, but to some extra assembly 
inserted in the caller function. I've seen that multiple times.

> > When you write in assembler, and don't use the C startup libraries, you
> > will get the program arguments and environment in the format supplied by
> > the OS, or more exact the OS's program loader.
> Exactly, and that format in the case of GTK is _cdecl, which means parameters
> as specified in code are pushed on the stack in a right-to-left order and the
> caller cleans up the stack when done. In ASM, this means you don't declare a
> function as _cdecl, you simply push the expected parameters in the right order
> and clean up the stack when the function returns.
True. But that doesn't change what Bill Kelly wrote, being that you need 
to retrieve the program arguments yourself, because Windows does not 
supply them in argc argv format.

regards,

Enno