Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!uwvax!umn-d-ub!nic.MR.NET!shamash!nis!ems!questar!midgard!dal
From: dal@midgard.mn.org (Dale Schumacher)
Newsgroups: comp.lang.c
Subject: A cast pointer is NOT an lvalue!? (ANSI C)
Keywords: X3J11, pointers, cast, lvalue
Message-ID: <479@midgard.mn.org>
Date: 6 Oct 88 20:09:42 GMT
Reply-To: dal@syntel.UUCP (Dale Schumacher)
Organization: The Midgard Realm, St Paul MN
Lines: 33

In porting my standard library routines to a newly developed C compiler,
I ran into a problem in the printf() formatting code.  In order to take
an arbitrary object off of the stack, and move the argument pointer to
the "next" argument, I used a pointer cast construct like this:

   value = *((long *) argp)++;

The original 'argp' is typed as a int pointer.  Since I'm working closely
with the compiler authors, I was able to talk to them about the compiler
not handling this construct and was told that the X3J11 proposal states
clearly (in a footnote) that the result of a pointer cast is NOT an lvalue!
It appears to late to get this changed in the standard, but I would like
to know WHY.  As a clearer example of what I consider valid use of a cast
pointer, consider the following:

    struct big_thing { /* several elements */ } big, *bp;
    char *p;

    if(p = malloc(sizeof(struct big_thing)))
        {
        bp = ((struct big_thing *) p);
        *bp = big;
        }
    if(p = malloc(sizeof(struct big_thing)))
        *((struct big_thing *) p) = big;

The first example, using the intermediate 'bp', is (as I understand it)
valid ANSI C, but the second example is not.  Why do I need to assign the
cast value to an intermediate in order to dereference it and assign something
to it's contents?  It seems to me that the value of any cast to a pointer
type should result in a modifyable lvalue, even if the expression being
cast is not an lvalue, since you could cast thexpression to a pointer
type, assign it to a pointer variable and then dereference it.