Path: utzoo!mnetor!uunet!husc6!mailrus!tut.cis.ohio-state.edu!uwmcsd1!marque!gryphon!sarima
From: sarima@gryphon.CTS.COM (Stan Friesen)
Newsgroups: comp.lang.c
Subject: Re: optimization
Message-ID: <3569@gryphon.CTS.COM>
Date: 24 Apr 88 22:24:06 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <4346@ihlpf.ATT.COM> <488@wsccs.UUCP> <20065@think.UUCP>
Reply-To: sarima@gryphon.CTS.COM (Stan Friesen)
Organization: Trailing Edge Technology, Redondo Beach, CA
Lines: 35

In article <20065@think.UUCP> barmar@fafnir.think.com.UUCP (Barry Margolin) writes:
>
>But my main objection to your blanket statement above is that it
>requires code that ACCIDENTALLY works when unoptimized to continue
>working when optimized.
>
	I want to add my affirmation of this! Code that ACCIDENTALLY works
is more common than many people realize. One of the worst cases was in a
program I was maintaining(written by someone else) that had something
like the following:

func(args)
type args;
{
	type .... /* whole bunch of auto variable declarations */
	.
	.
	int cur_pos;	/* Almost the last auto declared	*/
	.
	.
	.

	Code that uses cur_pos as if it were static;
}

	And it WORKED, at least until I made some minor changes elsewhere.
You see, the auto variables were "pushed" on the stack in the order of
declaration, and no other function had nearly as many auto variables as
func(). Thus the value in cur_pos was left undisturbed on the stack! Talk
about working *accidentally*!!!! (The programmer in question had already
been terminated for incompetence).
-- 
Sarima Carandolandion			sarima@gryphon.CTS.COM
aka Stanley Friesen			rutgers!marque!gryphon!sarima
					Sherman Oaks, CA