Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.sys.hp
Subject: Re: C Compiler Optimizer
Keywords: Optimizer C Complier
Message-ID: <3982@auspex.auspex.com>
Date: 29 Aug 90 21:27:13 GMT
References: <59169@bbn.BBN.COM> <766@tiamat.fsc.com>
Organization: Auspex Systems, Santa Clara
Lines: 34

>I didn't really worry about this, telling myself that not using "exit(0)"
>at the "normal" exit point of the program was probably bad programming
>practice.

Whether not using "exit(0)" is bad programming practice is a matter of
taste.  Neither using "exit(0)" *nor* "return 0" (or "return (0)" or
whatever) definitely *is* bad programming practice.  Most C
implementation - *all* valid ANSI C implementations - will, if you
return from "main()", exit with the exit status being the value returned
from "main()".  If you just fall off the end, you return a random value.

I believe there exist systems (SunOS 4.1 is one of them, I think) where
turning the optimizer off won't help.  Running the code through "lint"
may help, though; some versions of "lint" will catch attempts to fall
off the end of "main()", and HP's may be one of them.

>Like the other one, it wasn't really the compilers fault,

And, like the other one, "lint" may help, by catching the error...

>but I wish there was more info on what the optimizer will do so I won't get
>suprised on things like this.

...and, like the other one, there exist systems where turning the
optimizer off won't help.  SunOS 4.x is one of them; the run-time linker
uses the stack before "main()" does, and therefore there may be cruft
left on the stack with random values.

It's not really up to HP to enumerate all the cases of
common-but-incorrect practice where some particular release of their
optimizer will surprise you; in fact, it may not be practical for them
to do so.

"lint" really is your friend....