Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!mit-eddie!genrad!decvax!mcnc!rti-sel!dg_rtp!throopw
From: throopw@dg_rtp.UUCP (Wayne Throop)
Newsgroups: net.lang.c
Subject: Re: Must casting destroy lvalueness?
Message-ID: <657@dg_rtp.UUCP>
Date: Mon, 20-Oct-86 17:48:45 EDT
Article-I.D.: dg_rtp.657
Posted: Mon Oct 20 17:48:45 1986
Date-Received: Wed, 22-Oct-86 03:39:30 EDT
References: <4617@brl-smoke.ARPA>
Lines: 58
Summary: well... yes

> NET-RELAY.ARPA>@brl-smoke.ARPA (Scott)

> I'm relatively new to info-c and don't know if you've had this debate
> so just banish me to the archive if you have.

It has come around before.

> C pedants claim that casting destroys lvalueness.  Their argument is
> essentially that they can imagine a machine on which casting forces
> the use of a temp so lvalueness is gone.

Not that they can imagine such a machine.  That such machines actually
exist.  I am editing on one now.

> C users, on the other hand, find they have to program real machines not
> hypothetical ones and that almost all of these real machines don't use a 
> temp when casting.  For example, a useful and readable way to move a pointer 
> through a buffer containing a mixture of objects of different sizes is 
>
>                        ((OBJECT)pointer)++
>
> This construct is disallowed by Harbison's compiler. 

Not really very readible.  Let's take a similar example.  Would you
expect

        int i;
        ((short)i)++;

to do anything sensible?  If so, why?  If not, why should the pointer
case work sensibly?  After all, there *are* machines upon which integers
and shorts "mean the same thing", so the cast and increment could work
sometimes, right?

> I fear that the C standards committee is going to take away such practical 
> constructs and turn production quality C compilers into academic quality 
> ones.  Who knows, there may develop a brisk business in C compilers that 
> promise NOT to be standard conforming.

Only among those who don't care about portability or maintainability.

> How sayeth the C standard committee?  How sayeth the users?

I sayeth that if thou wishest to taketh an object as a different typeth,
thou mayest do so.  However, casts are not the way to do this in C, and
the practice is not portable.  If you must take the bits of one pointer
type as being those of another pointer type, use

                (*((some_type **)&p))++

or use unions like God intended.  Don't try to pervert casts to do
something they weren't intended for.  Casts convert, unions take-as.
The take-as operation is inherently non-portable.

--
"Thank you for your support."
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw