the real .pyc file

[Erik Max Francis]

Duncan Booth wrote:

> (BTW, I think the author of the article you indicated has got confused
> between implementation-defined and undefined).
> 
> Allow me to shall correct my wording:
> 
> "... your 'void main' isn't actually disallowed by the C standard, but
> it
> will invoke undefined behaviour which could do anything up to and
> beyond
> launching a nuclear strike."

The distinction he's making is that in C, an implementation is allowed
to define other signatures for main and document them.  No
implementation is required to implement any signatures other than those
two explicitly mentioned in the Standard, both of which return int.

In some ways this really is a distinction without a difference; _any_
implementation is free to take something explicitly in the realm of even
_undefined_ behavior, define it and document it, and you can rely on it
in that implementation.  But that doesn't change the fact that in the
general case, unless you know for a fact your implementation supports
it, you're talking about undefined behavior, and you should avoid it.

The C Standard just explicitly allows other implementation defined
signatures for main, possibly not even returning int.  Using them is
still undefined behavior, however, unless you _know_ that your
implementation supports them.  (C++ doesn't; any return value other than
int is undefined.  But, as the paragraph above points out, that can't
stop a compiler from implementing such a thing and declaring it valid
_on that implementation_.)

In one case it's "You shouldn't do this, but we can't stop implementors
from letting you"; in the other, it's "You shouldn't do this, but we'll
include a provision for implementors letting you if they so desire."

When portability is concerned, main should still always return int.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ The great floodgates of the wonder-world swung open.
\__/ Herman Melville
    Crank Dot Net / http://www.crank.net/
 Cranks, crackpots, kooks, & loons on the Net.