Xref: utzoo comp.lang.c:15546 comp.lang.c++:2426 Path: utzoo!attcan!uunet!lll-winken!ames!ncar!gatech!rutgers!att!westmark!mole-end!mat From: mat@mole-end.UUCP (Mark A Terribile) Newsgroups: comp.lang.c,comp.lang.c++ Subject: Re: Would *you* get caught by this one? Summary: What's the catch? Keywords: Assignops Message-ID: <144@mole-end.UUCP> Date: 14 Jan 89 11:49:57 GMT References: <139@mole-end.UUCP> Organization: mole-end--private system. admin: mole-end!newtnews Lines: 52 > Here's a simple C question on a point that caught me recently. Would *you* > get caught? > > When is a *= b not the same as a = a * b ? I've seen a number of replies, and all but one respondant has concentrated on things like the preprocessor or C++'s potential overloading of *= . There was also a mention of volatile. It's much simpler than that, and much uglier. To give credit where credit is due I will take the liberty of publishing part of a private correspondence: >From: Chris Torek > >a *= b is always equivalent if both a and b are simple variables >or expressions (i.e., no side effects, etc.). A number of compilers >do miscompile int_var *= float_expr, however. > >Chris Yes, they do. Given that the issue isn't directly addressed in either K&R, I wasn't going to come out and say which way is right, but Chris did and, since Microsoft (at least) agrees with him, I accept his judgement on the matter. (I remain open to a detailed examination of dpANS). Some compilers interpret i *= f as i *= (int) f This is obviously not the same as i = (int)( i * f ) and can produce wildly improbable results if the value of f is, let us say, 0.95 . >Subject: i *= f > >is supposed to mean i = (int)(i * f). PCC simply had a bug. (The >old PDP-11 compiler got it right...) > >Chris Since PCC did define the language for many people for many years, this ``simply'' has widespread ramifications. Chris gets a gold star and a bottle of Bactine for the burns suffered in discovering this. -- (This man's opinions are his own.) From mole-end Mark Terribile