🚀 go-pugleaf

In article <657@dg_rtp.UUCP> throopw@dg_rtp.UUCP (Wayne Throop) writes:
>Let's take a similar example.  Would you expect
>
>        int i;
>        ((short)i)++;
>
>to do anything sensible?  If so, why?

   In my opinion this should have the result

	* ((short *) &i) = (short) i + 1;

Obviously the result of this operation is machine-dependent (since the effect
of casting int to short is machine-dependent).  But on an appropriate machine
this does indeed have not only a sensible but a *useful* effect -- it will
increment the low bytes of i without carrying into the high bytes.

   At any rate the casting of int to short performs a fundamentally different
operation than does casting of pointers (in Wayne's terminology, the former
"converts" and the latter "takes-as"), and so it is not necessary for one to
make sense in order for the other to be allowed.

   Note also that on most machines the statements

	int *p;
	((int) p)++;

makes sense (it increments the address referenced by p by the addressing unit
of the machine).  In fact this is arguably the correct way to use the value
produced by 'sizeof';

	(int) p += sizeof (foo);

makes sense on any machine where 'sizeof' gives results in multiples of the
addressing unit of the machine, whereas the more common alternative

	p = (int *) ((char *) p + sizeof (foo));

is both clumsier and makes the unnecessary assumption that sizeof (char) == 1.


   Another justification for casting of lvalues is the case of register
variables.  In this case Wayne's alternative syntax doesn't work:

	register int *p;
	(* ((foo **) &p))++;		<== ERROR

But the idea of casting (or "taking-as") the pointer p as a pointer to foo is
still perfectly valid, and the proposed syntax

	((foo *) p)++;

still makes sense, and can be understood and implemented by a compiler.

   -- David desJardins