Incrementing after a cast

[Tom Stockfisch]

In article <2029 at brl-adm.ARPA> .csnet"@relay.cs.net> writes:
>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.
>
>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.

Your notion that

	(sometype *)p

could be an lvalue is not compatable with the notion of C's model of
computation.  As has been mentioned, even if you allow the "++" to operate
on the "(sometype *)p", according to C's model of computation the cast
value would exist in a temporary, and the TEMPORARY would be incremented,
not p.

>makes perfect legal, technical, and useful sense and these happen to be C 
>machines. Why lots of people with ordinary machines can't do something 
>useful, intuitive, and natural because some solder-crazed EE somewhere might,
>just might mind you, someday do something unnatural to his memory system is 
>beyond me.  
>...
>If you insist on being strict, here's a definition of ((sometype *)p)++ 
>which will work on any machine:
>
>	"Think of the bits refered to as p as a (sometype *).
>	 If don't have enough bits or you have too many bits 
>	 do something reasonable.  Now increment the (sometype *)
>	 you're thinking of.  Now put the results back into p.  
>	 If you	 don't have enough bits or you have too many bits, 
>	 do something reasonable."
>

Someone posted a more precise definition that translates the construct
into currently legal C.  I believe it was something like

	((sometype *)p)++

is defined to mean

	(*(sometype **)&p)++

but now I forget if the value of this expression is of the desired type.
I think your definition assumes that pointers will differ only in width,
and not in represention.  Don't forget that on many machines the interpre-
tation of a bit pattern is different for character pointers than for other
types.

>And no noise please about doing something reasonable because 1) we do it 
>all the time with numbers so why not with pointers too, 2) it's probably 
>what you want any way, and 3) it'll never have to be done on machines that 
>are reasonable to begin with. (By the way there is no reason why ((x+1) = 10)
>shouldn't work too.)

This violates the C design principle that an expression can be an lvalue --
what do you do with
	
	(x + y) =	10

What rule would you propose for assignments?  Some rule like:

	expr-containing-a-single-lvalue =	expr

will reject the "(x+y) =" case, but then what do you do with

	f(x) =	expr

Can you think of a scheme which wouldn't double the size of C's grammar?
I think that any scheme that allows "(sometype *)p" to be an lvalue in some
contexts will severely complicate C's grammar.  We don't want a language
where the special-cases part of the definition is larger than the perfectly-
general-rules section.

>I forsee a day when there are two kinds of C compilers: standard ones and 
>useful ones ... just like Pascal and Fortran.  Are we making progress yet?

The usual complaint about C is that it's TOO useful.  That is, that almost
any combination of tokens yields a valid program (or so say its detractors),
so that the compiler rarely discovers errors.
Your proposal would certainly contribute to this,
since it is usually an error for a cast to be an lvalue.

Recall all the confusion resulting from
the fact that arrays are sometimes the whole array and sometimes
the pointer to the first element, and the declaration "char *p" is
sometimes equivalent to "char p[]", and sometimes completely different.
Do you really want cast-expressions to be sometimes lvalues and
sometimes not?

And the main (sole?) advantage of this extension is so you can shave
two characters off the expression

	(*(sometype **)&p)++

I rest my case.

|| Tom Stockfisch, UCSD Chemistry	tps%chem at sdcsvax.UCSD