Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!emory!gatech!usenet.ins.cwru.edu!ncoast!davewt From: davewt@NCoast.ORG (David Wright) Newsgroups: comp.sys.amiga.programmer Subject: Re: Side Effects == Rattlesnakes -- watch out for them Re: Compiler code (was a flame fest) (now a lesser flame fest) Message-ID: <1991May4.161920.23798@NCoast.ORG> Date: 4 May 91 16:19:20 GMT References: <24503@well.sf.ca.us> <1991May4.061257.14959@zorch.SF-Bay.ORG> Organization: North Coast Public Access Un*x (ncoast) Lines: 32 In article <1991May4.061257.14959@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> jsmoller@jsmami.UUCP (Jesper Steen Moller) writes: >>> Oh, by the way: func(a++) Is "a" increased before or after the >>> function call. I think I once read in K&R that it was undefined, but >>> I might be mistaken. >Which still leaves the wide open "gotcha" that if func() modifies "a" >by a side effect during execution, all bets are off as to whether the >pre-call or the post-call value is what gets incremented and stored >back in "a". Really? How can it do this unless you are passing a *pointer*? and if "a" is a pointer, and is passed to func(), there is no way for func() to modify "a" itself, only what "a" *points to*. The only way that func() could change "a" would be is you passed a pointer to "a" itself if "a" is not a pointer, or a pointer to the pointer named "a" if it is, which would be tricky in either case to create something like "func(a++)" with this functionality (at least I can't think of a good reason to do it outside of an entry for the "obfuscated C contest"). Calling "func(a++)" should be perfectly safe, assuming that "a" is not a global value, and you should of course use a few global values as possible, and therefore know how they are changed and what results to expect. Dave > >Best rule for C side effects -- don't. > >Kent, the man from xanth. >