davewt@NCoast.ORG (David Wright) (05/04/91)
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. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
comeau@ditka.Chicago.COM (Greg Comeau) (05/05/91)
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. >> Nope, not undefined. a is evaluated, and passed to the function when >> it is called, and then is incremented. This *is* guaranteed. >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". Not quite wide open in this situation. I believe a message passed through here a few days ago which correctly stated that although evaluation orders are still not dictated, that there is a sequence point generated at function call time. >Best rule for C side effects -- don't. ... although that rule is most always a good one! - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ 2.1 Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/06/91)
In article <1991May4.161920.23798@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >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() Well, 'a' could be a global, or part of a structure that's accessible through other means. But I believe expressions in a function call are sequenced so all side effects will have been done by the time the function is called. You don't know which ORDER the expressions in a function call are calculated though. >> >>Best rule for C side effects -- don't. >> >>Kent, the man from xanth. >><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA