A cast pointer is NOT an lvalue!? (ANSI C)

Dale Schumacher dal at midgard.mn.org
Wed Oct 12 08:15:22 AEST 1988


In article <8663 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|In article <479 at midgard.mn.org> dal at syntel.UUCP (Dale Schumacher) writes:
|>   value = *((long *) argp)++;
|
|A cast is the same as assignment to an unnamed temporary variable.
|The ++ in your example would have to increment the temporary variable,
|not the original variable argp.  That is clearly not what you wanted.

Ok.  This makes sense.  Since my posting I also discussed this with
Shane McCarron, who explained problems involving pointers of different
sizes and the possibility of distinct storage for different types,
which brings up a later question with Chris Torek's response.

|Anyway, you should be using either the old <varargs.h> or the new
|<stdarg.h> macros to pick up arguments from a variable argument list.
|What you were trying to do cannot be done portably any other way.

The printf()/scanf() code was written before I implemented <stdarg.h>
macros and I haven't gone back to change it yet.  I probably should.

In article <13912 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
|In article <479 at midgard.mn.org> dal at midgard.mn.org (Dale Schumacher) writes:
|
|>As a clearer example of what I consider valid use of a cast
|>pointer, consider the following:
|
|But this *is* valid:
|
|>    struct big_thing { /* several elements */ } big, *bp;
|>    char *p;
|[...]
|>    if(p = malloc(sizeof(struct big_thing)))
|>        *((struct big_thing *) p) = big;
|>
|>...  Why do I need to assign the cast value to an intermediate in
|>order to dereference it and assign something to it's contents?
|
|You do not.  The result of a cast is NEVER an rvalue, but the result of
|an indirection *is* an lvalue.

Is this really legal in X3J11?  If an implementation stores different
object types in different areas of memory, then wouldn't that fail also?
How would one implement malloc() on such a machine?



More information about the Comp.lang.c mailing list