Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!lambert
From: lambert@mcvax.uucp (Lambert Meertens)
Newsgroups: net.lang.c
Subject: Re: Must casting destroy lvalueness?
Message-ID: <7132@boring.mcvax.UUCP>
Date: Thu, 6-Nov-86 03:07:22 EST
Article-I.D.: boring.7132
Posted: Thu Nov  6 03:07:22 1986
Date-Received: Fri, 7-Nov-86 22:05:47 EST
References: <4617@brl-smoke.ARPA> <657@dg_rtp.UUCP> <55@cartan.Berkeley.EDU> <663@dg_rtp.UUCP>
Reply-To: lambert@boring.uucp (Lambert Meertens)
Organization: CWI, Amsterdam
Lines: 35
Keywords: extension
Summary: Yes. But why?
Apparently-To: rnews@mcvax

I still don't get what is so fundamentally wrong with the following
*addition* to C, which it seems to me that desj@brahms (David desJardins)
is arguing for:

    A cast (T)E in a context where an lvalue is required
    stands for *(T *)&(E) and so is lawful if the latter
    would be allowed here.

For example, this would then make the following lawful:

    int i;
    char *p = (char *)&i;
    ++(int)*p;

At least, in `my' cc (BSD 4.3) everything works as expected if I

    #define Lcast(T,E) (*(T*)&(E))

and then use

    ++Lcast(int, *p);

(I don't know if this is allowed by the ANSI C draft.)  Note that I am not
particularly arguing in favour of this extension, the fact being that this
is one of the areas where I can live with current C.  But neither do I see
a reason to get upset about it.  It allows you to write pretty meaningless
things, but that is the case already for current casts.  One thing that is
certain is that it does not invalidate existing code.  Also, it seems
consistent to me with the design philosophy of C: start by putting some
very confusing things in (pointers vs. arrays, here pointers vs. lvalues),
then legitimate some of the most obvious unambiguous mistakes.

-- 

Lambert Meertens, CWI, Amsterdam; lambert@mcvax.UUCP