Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpcc01!hpcuhb!hpda!hpwala!hpavla!kitchin
From: kitchin@hpavla.AVO.HP.COM (Bruce Kitchin)
Newsgroups: comp.lang.c
Subject: Re: main() arguments, was Re: typedef-ing an array
Message-ID: <9130014@hpavla.AVO.HP.COM>
Date: 9 Jul 90 17:59:51 GMT
References: <4238@jato.Jpl.Nasa.Gov>
Organization: Hewlett-Packard Avondale Division
Lines: 25

>> Well, I tried it on as many compilers as I could get my hands on, and they
>> all worked.

Yes, but proof of what?  The only thing that you proved is that for those 
compilers that you were able to get your hands on, the writers of those compilers chose to make it work the way you did it.  However, what I believe others are
saying is that if you declare main as returning int and taking either zero or
two arguments of the appropriate type as defined by ANSI-C, then your program
will work on ANY ANSI conforming compiler and it will work if you use return
to terminate the main function or you use exit().  I believe that it will
also work for any K&R conforming compiler and between the two of them you 
should have all bases covered.  If you find one that doesn't work when you
follow ANSI's rules, you would have legitimate reason to complain to the
compiler writer.  However, if you declare main in any other way, ANSI clearly
states that any current or future compiler writer for any reason that seems
good to them can complain that your program is written wrong or even to emit
code that will lead to catastrophic program failure when executed.

I have seen in my own experience and even more in watching others doing the same thing, that using EMPIRICAL evidence as a basis for not obeying the docs 
is the first step towards an unexpected disaster just waiting to get you when
you are least expecting it.  I have used empirical evidence to show that
a product doesn't meet the documentation when the doc's say that something will
work and it clearly doesn't work.  But I've learned not to take advantage of
undocumented things that 'work'.  I've seen commercial products go belly-up
when a new revision of the supporting hardware or software did not conform to
some undocumented, but depended on, behavior.