Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site btnix.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!amd!vecpyr!lll-crg!seismo!mcvax!ukc!icdoc!ist!btnix!lam
From: lam@btnix.UUCP (lam)
Newsgroups: net.lang.c
Subject: Re: how has C bitten you? (and a sidetrack)
Message-ID: <16@btnix.UUCP>
Date: Fri, 23-Aug-85 06:48:29 EDT
Article-I.D.: btnix.16
Posted: Fri Aug 23 06:48:29 1985
Date-Received: Tue, 20-Aug-85 06:29:58 EDT
References: <4051@alice.UUCP> <2600011@ccvaxa>
Organization: British Telecom, Ipswich, England
Lines: 34
Xpath: icdoc ivax



[*** The Phantom Article Gobbler Strikes Again ***]
> > > 	int i, a[10];
> > > 	for (i = 0; i <= 10; i++)
> > > 		a[i] = 0;
> > > 

> > This looks to me like it will simply overwrite one int's worth of
> > memory beyond the end of the array "a" with the value 0.  Granted,
> > depending on what happens to be after "a", this can have disastrous
> > results, but is there really an implementation in which it will
> > (reliably) lead to infinte looping?
> ----------
> Yes.  Any implementation that allocates the space for i following the
> space for a.

The cause of the infinite loop is due to the storage allocation.
	i.e.	&i == &a[10]
   causing i to be overwritten with 0 when i is 10.

The more interesting thing is that on some compilers, the infinite
   loop does NOT occur.  Lo and behold, the OPTIMISER comes into play.
   If i is put in a Register at the start of the for(), a[10] = 0 
   will indeed overwrite i in memory but not the register !!! and the
   loop terminates normally.
   What's worse, the optimiser has in this case hidden a program bug!!!

Thus the moral:

	"Don't just test your code once.  Test it again, this time
    	 turn the optimiser OFF first".

------------------------------------------------------------------
	Onward Lam 
	CAP Group, Reading, England.