Xref: utzoo comp.society.futures:2224 comp.lang.misc:5704
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.society.futures,comp.lang.misc
Subject: Re: C's sins of commission
Summary: Bug or feature?
Message-ID: <2673@l.cc.purdue.edu>
Date: 23 Oct 90 10:13:01 GMT
References: <5006@uqcspe.cs.uq.oz.au> <64616@lanl.gov> <5088@uqcspe.cs.uq.oz.au> <5EJ64J3@xds13.ferranti.com>
Followup-To: comp.lang.misc
Organization: Purdue University Statistics Department
Lines: 23

In article <5EJ64J3@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
> In article <152323@felix.UUCP> asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) writes:
> > Nope.  C (at least) allows for variables to be 'static'.  No need
> > for side-effects to maintain the function's internal state.
> 
> Those *are* side-effects, since they mean the same function may return
> different values on successive calls with the same calling sequence. This
> has the same effects on predictably and optimisation as more obvious side
> effects.

I have yet to see a random number. or pseudo-random number, procedure which
did not exploit this.  The same is true for uses of buffers, reading external
media, etc.  It is also the case when one makes calls by reference, and
uses code to change the values of the arguments.  This even applies to
a subroutine to multiply two matrices.

This means it is the programmer who must decide, and pass on the information
to the compiler, about the side-effects.  Sometimes, but not always, the
compiler can tell by looking at the global code.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)