🚀 go-pugleaf

In article <12049.Jun2922.08.1391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>> Basically, this was specified to cause undefined behavior because
>> that's exactly what it does.
>That's what it does in historical implementations, but ...

Ok, this really isn't worthy of protracted discussion, but what I mean
is that the natural, simplest implementation of function return would
not (as well as historically did not) invent well-defined values for
programs that do not at all specify the values.  In the case of default
initialization of statics, while it may appear that the programmer has
left the contents unspecified, he really hasn't, because K&R guaranteed
that they would contain 0.  There was never any guarantee that return
from an int-valued function would create some well-defined value (say,
0), but K&R did make it clear that so long as one didn't intend to use
a value there was no need to return one.  (This may have been different
if void-valued functions had existed from the beginning.)  As the only
acknowledged public specification of the C language, K&R had to be
taken as the main guide for settling questions about the existing rules.

Given that anonymous return in general produces an unspecified value,
anonymous return from main() naturally would do the same.  To make it
different from other functions would require a special-case wart, and
the one the standard already requires (accepting "int main(void)") was
already rather controversial.  ("int main(void)" would probably not
have been blessed were it not for the fact that K&R indicated clearly
that programmers could expect it to work, so there was a huge amount of
existing, arguably correct, code that relied on that behavior.)

While you can argue that you would like to add some more default rules
such as automatic 0 values for anonymous returns, that qualifies as new
invention and thus joins literally hundreds of similar suggestions in
the "not appropriate for standardization" category.