Ultrix CC bug?

[Maarten Litmaath]

bl at infovax.UUCP (Bj|rn Larsson) writes:
\...	*((long *) p)++		has the value of the *long* pointed
\				to by p, and the *long* pointer is
\				set to point to the next long (i.e.
\				if sizeof (long)== 2*sizeof(short)
\				then p will be incremented by two,
\				counted in short's).
\
\  Any objections? I could add that both Turbo C, MicroSoft C, and the
\MicroTek C 68000 cross-compiler compile this as I believe 'correctly'.

It seems all those compilers are wrong...!
Now where's that article I posted not too long ago to comp.lang.c?
Aha!  Here it is.
Allright.  A compiler that allows the abovementioned construct is wrong for
two reasons:

1)	It allows the `++' operator to be applied to an Rvalue expression;
	only Lvalue expressions may be operand of an increment operator, e.g.

		x++
		a[i]++

	This isn't so strange:

		x++
	
	is equivalent to

		x = x + 1

	which doesn't make sense for arbitrary (Rvalue) expressions.
2)	It increments the wrong variable; a cast is equivalent to an
	assignment to an invisible temporary variable (with the usual
	restrictions and conversions):

		foo	x;

		... (bar) x ...

	becomes

		foo	x;
		bar	cast_tmp;	/* `invisible' temp variable */

		... (cast_tmp = x) ...
	
	If we write the latter expression as

		(cast_tmp = x, cast_tmp)

	it's clearly `cast_tmp' which should be incremented (if a `++'
	operator is appended), were this possible at all; definitely NOT `x'.
-- 
   creat(2) shouldn't have been create(2): |Maarten Litmaath @ VU Amsterdam:
      it shouldn't have existed at all.    |maart at cs.vu.nl, mcvax!botter!maart