Xref: utzoo comp.lang.c:12334 comp.arch:6241
Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!decwrl!alverson
From: alverson@decwrl.dec.com (Robert Alverson)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Explanation, please!
Message-ID: <758@bacchus.dec.com>
Date: 2 Sep 88 17:27:48 GMT
References: <638@paris.ics.uci.edu> <dpmuY#2EBC4R=eric@snark.UUCP> <189@bales.UUCP> <9064@pur-ee.UUCP>
Organization: DEC Western Research Lab
Lines: 29

In article <9064@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
>	Incidentally, this ran about 8x faster (on a VAX 11/780) than using
>	the usual copy loop.  Unfortunately, the above code should have been
>	written as:
>
>	if (n & 512) {
>		*(((struct t512 *) q)++) = *(((struct t512 *) p)++);
>	}
>	...
>
>	but, for some unknown reason, the VAX C compiler didn't like that.
>
>
>Enjoy.
>					hankd@ee.ecn.purdue.edu
Actually, the VAX C compiler was completely correct.  Attempting
to post-increment the result of a cast is not legal C.  One way
around this is to use a little extra indirection:

    char* p;

    /* was:   ((int *)p)++; */
    (*((int **) &p))++;		/* phew! */

The reasoning is that the result of a cast is an expression, not a
lvalue.  Quite often, compilers relax this rule for coercions which
produce no code.  In this case, it looks like the VAX C doesn't

Bob