Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!cuae2!ihnp4!ethos!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP (Wayne Throop) Newsgroups: net.lang.c Subject: Re: Must casting destroy lvalueness? Message-ID: <667@dg_rtp.UUCP> Date: Mon, 3-Nov-86 17:21:43 EST Article-I.D.: dg_rtp.667 Posted: Mon Nov 3 17:21:43 1986 Date-Received: Wed, 5-Nov-86 21:22:54 EST References: <4617@brl-smoke.ARPA> <657@dg_rtp.UUCP> <61@cartan.Berkeley.EDU> Lines: 85 Summary: [Refutation of] More [bogus] reasons for casting lvalues. > desj@brahms (David desJardins) >> throopw@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 !mcnc!rti-sel!dg_rtp!throopw