Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!ukc!dcl-cs!gdt!gdr!exspes
From: exspes@gdr.bath.ac.uk (P E Smee)
Newsgroups: comp.std.c
Subject: Re: observability
Message-ID: <1989Sep8.091010.12450@gdt.bath.ac.uk>
Date: 8 Sep 89 09:10:10 GMT
References: <1237@gmdzi.UUCP> <10885@smoke.BRL.MIL> <242@ssp1.idca.tds.philips.nl> <10937@smoke.BRL.MIL> <1989Sep6.160709.4890@light.uucp> <1989Sep6.183349.2866@jarvis.csri.toronto.edu> <28946@news.Think.COM>
Reply-To: exspes@gdr.bath.ac.uk (P E Smee)
Organization: University of Bristol c/o University of Bath
Lines: 30

In article <28946@news.Think.COM> barmar@think.COM (Barry Margolin) writes:
>This reminds me of the old stories about an optimizing Fortran
>compiler that was doing amazingly well on benchmarks because it
>optimized away the entire program because it had no I/O statements.

Totally valid in FORTRAN.  Since the spec does not require preservation
of faults/exceptions (and indeed a program which produces them is
probably invalid) and any flags are not guaranteed to come back from a
subroutine.  Any FORTRAN program which does no I/O, does not change its
arguments or return a value, does not modify any variables in COMMON
(external storage), and does not call any other subroutine or function
which might do any of these, can be gutted.  The optimized null
procedure is identically equivalent to the original in FORTRAN terms.
Similarly, any block of code which does not contribute to such effects
can be removed from the program.  The C standard imposes different
requirements, and it appears that this FORTRAN approach would not be
valid in C -- though one might ask why you would want to write a chunk
of code that has ZERO effect.

(The counter-example people inevitably come up with is 'maybe the
program is meant to be a timing loop'.  The tired answer is 'if you
want a time delay, you should tell the operating system to put you to
sleep for some period of time, rather than wasting CPU cycles twiddling
your thumbs.  The other users of your multi-user system will thank you
for it.)
-- 
 Paul Smee               |    JANET: Smee@uk.ac.bristol
 Computer Centre         |   BITNET: Smee%uk.ac.bristol@ukacrl.bitnet
 University of Bristol   | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk
 (Phone: +44 272 303132) |     UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes