Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!ukma!psuvax1!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.std.c
Subject: Re: Must main return a value?
Message-ID: <12049.Jun2922.08.1391@kramden.acf.nyu.edu>
Date: 29 Jun 91 22:08:13 GMT
References: <16575@smoke.brl.mil> <1991Jun29.002410.27632@aero.org> <16582@smoke.brl.mil>
Organization: IR
Lines: 27

In article <16582@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
> Either that, or you really believe that an implementation
> could document what would happen for every program that returned
> garbage instead of a deliberate value, where the garbage is NOT
> specified in the program (unlike the case for the part of 4.10.4.3
> that you quoted).

I really believe that an implementation could document what would happen
for every program that returned garbage instead of a deliberate value.
At most it would take a special case in the compiler: ``Oh, a void
return inside main? Let's make that return 0.'' Then the documentation
would reflect this.

> Basically, this was specified to cause undefined behavior because
> that's exactly what it does.

That's what it does in historical implementations, but ANSI tightened up
on a lot of minor points, and they could easily have taken care of this
one. I'm not saying this is necessarily a good idea, but you can't just
throw out the question. Why would it have been bad to insist on
implementation-defined behavior? *Why* is undefined a better idea?
``That's exactly what it does'' is not an excuse; if you took that
logic, it would be undefined whether static variables are initialized to
0, undefined whether unions of structs beginning with the same type in
fact overlapped, and undefined whether int a[n]; a + n is always valid.

---Dan