Does your compiler get this program right?

[David Goodenough]

>From article <4082 at cs.utexas.edu>, by meyering at cs.utexas.edu (Jim Meyering):
> In article <2298 at cbnews.ATT.COM> lvc at cbnews.ATT.COM (Lawrence V. Cipriani) writes:
> 	>A friend of mine found a bug in his C compiler.  He found
> 
> It's not a bug.
> 
> 	[...deleted commentary, code]
> 	>*f++ += *g++;		/* miscompiled line */
> 
> The standard does not specify the order of evaluation for such
> statements.  It's easier to see the ambiguity if you try to rewrite
> it without the += notation.  Which do you choose?
> 
>  1) *f++ = *f++ + *g++;
>  2) *f++ = *f + *g++;
>  3) *f = *f++ + *g++;

Am I missing something, or is the standard broken? To my mind, the statement

	*f++ += *g++;

means only one thing: take the contents of pointer g, add it to the contents
of pointer f (i.e. add what g points to, to what f points to). Now make g and
f point to the next entries in whatever arrays they are pointing to. The whole
point behind the += operator is that the address on the left hand side
IS ONLY EVALUATED ONCE. Hence there is no ambiguity:

	*f += *g;
	f++;
	g++;

should be the only way the above statement can be done (with the caveat that
the order of the f++ and g++ is A: undetermined, B: irrelevant). However the
*f += *g MUST COME FIRST.

In particular, if I say

	extern char *zoot();

	*(zoot()) += '\001';

and zoot() gets called twice in evaluating the above statement, then I'm
going to ditch my C compiler because it's broken. If the standard says that
zoot() can be called twice, then I'm going to ignore the standard, because
IT'S broken.
-- 
	dg at lakart.UUCP - David Goodenough		+---+
							| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp at harvard.harvard.edu	  	  +---+