Re: generalized lvalues

[Ziemowit Laski <zlaski at apple dot com>]

On 19 Nov 2004, at 13.50, Michael Matz wrote:

> > (1) #define foo(x) *(a, b, x)
> > (2) ((long*) p)++
>
> Actually, from my experience looking at assorted packages which are 
> tried
> to be build with 4.0, the latter use is most common.  I.e. casting a
> pointer to some type to implicitely specify how much it is incremented.
> Some software is very much known for using such constructs (wine, rpm,
> elfutils, dietlibs, many others) .  I even tend to say, that such 
> usage is
> well defined (within certain limits), although I admit that it's not 
> ISO
> C99.
>
> <rant>
> All the whining about how unspecified this is, and how the writer of 
> the
> code deserve to be bitten, is just language lawyer masturbation (which 
> I
> also very much enjoy when closing bugreports about this or that 
> compiler
> bug with INVALID), but it doesn't change the fact, that there are quite
> some packages out there actually using such extensions.  This
> cast-as-lvalue extension removal is one of the bigger items which 
> result
> in much work for package maintainers (not so much for C++, as there 
> anyway
> this extension wasn't used much).
> </rant>
>
> So, if anyone wants to bring it back, with defined semantics of course
> (like for instance memory accessed through a casted pointer is well
> defined (not outside the memory for the object accessed), and only for 
> C)
> I'm all ears.

As I've alluded to in an earlier e-mail, bringing back the entire 
cast-as-lvalue
functionality is probably not necessary (and yes, it can interact 
rather badly
with C and C++, as I have finally been convinced).  However, I did make 
a
suggestion that we could create a special flag (e.g., 
'-fassign-to-cast' or
some such) that would allow an assignment (including ++ and --) to a 
cast.

Would such an approach be acceptable?

Thanks,

--Zem