main() arguments, was Re: typedef-ing an array

Kaleb Keithley kaleb at mars.jpl.nasa.gov
Wed Jul 4 06:00:03 AEST 1990


In article <25273 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
-
- [examples of assembly code generated by compiler deleted]
-
-Unfortunately for us, the thing that calls main() with argc and argv
-put a return value pointer into 2(sp), so that we called foo() with
-the result of `return value pointer == 1 ? 0 : 1' rather than with
-the result of `argc == 1 ? 0 : 1'.  If we try to examine the value of
-argv, we find instead the value of argc.  Indeed, we could write our
-main as

Well, wait a minute; what you say is all well and good, but let's take
some real-world considerations.

1. If exit is used, the return value is never seen by the run time.  In
tracing through the M'soft C run-time, we see the following (and I 
suspect the same in UNIX run-time, but not having traced through it,
can't vouch for it):

    (in psuedo-code)
    setup_and_init();
    exit_code = _main();
    _exit(exit_code);

    and of course _exit terminates the program in some machine dependent
    way, in DOS, it's int 20H, or int 21H function 0.

So, if exit() in preference to return, the value on the stack when main
returns is meaningless, because it will never run.  So who really cares
what code is generated by default.

Don't believe me?  Try this:
void main () { exit(0); printf("I'll never be printed\n"); }

2. Who calls main(), except the run-time?  I don't want to make glittering
generalizations, but I suspect that very few programs call themselves.  If
they did, exit() might defeat their intent, and probably wouldn't be used
in that case.

3. We as software developers shouldn't be trying to anticipate what kind of
code the compiler will generate.  (Oops, there's a glittering generality!)
With the current state of optimizers, can we really predict anything?  We
should concentrate on finding efficient algorithms.  Knowing what kind of
code will be generated on machine A doesn't tell us anything about machine B.

Don't get me wrong, I think knowing (in a general way) how the compiler
generates code is a valuable thing indeed, but worrying about the *correctness*
of generated code that will *never* be run seems a little pointless.  If 
everything between the _exit function call and the return is dead code, why
the compiler put it there?  Because it's too stupid to not put it there.  
To reiterate, main() is a function like any other (K&R 2nd Ed.) The compiler 
has to put a return at the end of a function, that's the only thing it knows 
how to do.  Does it return valid information?  No, it doesn't return anything
because it *never* runs!

->I know that both UNIX and DOS (M'soft C compilers anyway) support
->char **envp ... as the third parameter to main.
-
-to write a portable program, you must not use this invisible third argument.

Can you quote a reference to this assertion?

kaleb at thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

"So that's what an invisible barrier looks like"



More information about the Comp.lang.c mailing list