Incrementing after a cast

[Guy Harris]

>From the original article:

> >Casts are conversions? Oh? You'd never know it looking at the code that
> >out of my C compilers ... including Harbison's!  He just regards away.

Oh, really?  The code generated for

	float f;
	int i, j;

	f = (float)i + (float)j;

just adds two integer variables without converting to float?  How
interesting....

If the compiler *can* convert pointers without doing any computation, it
will; however, that does not mean this is the *definition* of such a
conversion.

> >The fact that there are machines which would like to have C compilers on 
> >which ((sometype *)p)++ doesn't work as a "regard as" only means that 
> >these machines aren't compatible with a lot of people's notion of C's model 
> >of computation.

That's their problem; they just don't understand C's model of computation.

>From the followup:

> And the main (sole?) advantage of this extension is so you can shave
> two characters off the expression
> 
> 	(*(sometype **)&p)++

Well, not really.  This wouldn't work if "p" were of storage class
"register".

What people seem to want to do with this sort of construct is to generate
the "right" machine code for what they're trying to do.  They want to
generate something using the machine's auto-increment addressing mode, if
the machine has one.  If they wanted to write more portable code, they could
do

	*(sometype *)p ...
	p += sizeof (sometype);

and some compiler might even be clever enough to generate the right code.

I guess either not enough compilers are clever enough, so they want to use
something like Mesa's "LOOPHOLE" operator, which merely reinterprets a
bucket of bits.  It's interesting to note that C lacks this operator, while
some languages with stronger type checking have it.