|m68k gcc/egcs question firstname.lastname@example.org (Zoltan Kocsi) (1999-09-20)|
|Re: m68k gcc/egcs question email@example.com (David Williams) (1999-09-24)|
|Re: m68k gcc/egcs question firstname.lastname@example.org (1999-09-24)|
|Re: m68k gcc/egcs question email@example.com (James Jones) (1999-09-27)|
|Re: m68k gcc/egcs question firstname.lastname@example.org (1999-09-28)|
|Re: m68k gcc/egcs question email@example.com (Zalman Stern) (1999-10-01)|
|Re: m68k gcc/egcs question firstname.lastname@example.org (Zoltan Kocsi) (1999-10-01)|
|Re: m68k gcc/egcs question email@example.com (Zalman Stern) (1999-10-03)|
|Re: m68k gcc/egcs question firstname.lastname@example.org (Graham Murray) (1999-10-03)|
|From:||email@example.com (Ojala Pasi 'Albert')|
|Date:||28 Sep 1999 00:26:33 -0400|
|Organization:||Tampere University of Technology|
|References:||99-09-078 99-09-103 99-09-111|
James Jones <firstname.lastname@example.org> wrote:
>the result undefined...OK, we'll sidestep that issue; it should be
>possible to write (in C++ but not in C)
> cp = &(c = 10);
Although worded differently, the expression c = 10 only is a value,
not object, thus you can't convert it into a lvalue. The excerpt
you quoted only talked about types, not storage.
It is still to be argued whether you are supposed to read the
value back for volatile variables though. Both implementations
have their ground. It depends on whether you define the assignment
expression value to be the value assigned or the value of the
object after the assignment.
I would select (and actually did select for my DSP C compiler) the
first interpretation: the value of assignment expression is the
value assigned. If the variable is volatile, the value must be
stored exactly once before any other volatile access, but will
not be read back.
Return to the
Search the comp.compilers archives again.