Must casting destroy lvalueness?

[Wayne Throop]

> desj at brahms (David desJardins)
>> throopw at dg_rtp.UUCP (Wayne Throop)

>>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;

"Opinion." OK.  Fine.  But David's opinion clearly and trivially differs
from that of the folks who designed and implemented the C language.  In
particular, David's interpretation of casts has them sometimes
converting, and sometimes taking-as.  K&R, H&S, and the draft X3J11
standard are all as clear as they can be... casts *ALWAYS* convert.

> Obviously the result of this operation is machine-dependent (since the effect
> of casting int to short is machine-dependent).

Casting is *NOT* machine dependent in anywhere near the same sense that
taking the bits of an integer as if they were a short is.  Again, David
has a fundamental misunderstanding of what it is that a cast does.  It
*ALWAYS* converts.  Casting an int to a short is machine dependant in
the limit, but in the case where the two types share range, the result
is dependable and machine independant.  The draft X3J11 standard even
outlines some guarantees on what this range of portable casting is.

> 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.

Oh, please!  Just because some illegal construction can be made to do
something useful on some machine-or-other is no reason to attempt to
legislate it so.  Especially when this operation can be specified with
legal C constructs.

>    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.

False, false, false!  Pointers have differing bit-wise formats, just as
arithmetic types do.  The common examples are the word-addressed
machines, where the byte or character address format differs from the
"natural" architectural pointer format.

> In fact this is arguably the correct way to use the value
> produced by 'sizeof';
>         (int) p += sizeof (foo);

One can argue it.  And anybody that did so would be wrong.  A pointer
taken-as an integer need not address in sizeof-unit-sized chunks.  In
fact, there are many machines where this is not the case.  Further,
there are machines where pointers aren't even the same *SIZE* as
integers.  Surely these two trivial, well-known facts should point out
some flaws in any such argument?

>    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.

Rubbish.  David just argued in a previous note that casts retaining
lvalueness was justified because lvalues and addresses are "the same
thing".  Now he claims that register values further support this
ludicrous position, despite the fact that they are a counterexample to
his previous justification!!  Puhleeeze!


I'm trying hard to be civil here, honest I am, but really!  If somebody
wants to act like a C guru, it might help to learn some C first.  Get
this straight:  casts convert.  Unions take-as.  A cast of a pointer can
take-as the bits it points to, BUT NOT THE POINTER ITSELF!  The take-as
operation is completely machine dependant, and code using it is rendered
non-portable by this use.  This is trivial, basic stuff folks.  You
can't even *BEGIN* to understand C until you get *THIS* straight.

--
"Don't do this at home, kids..."
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw