Re: generalized lvalues -- patch outline

[Ziemowit Laski <zlaski at apple dot com>]

On 23 Nov 2004, at 1.30, Nathan Sidwell wrote:

> Ziemowit Laski wrote:
>
> > The semantics are that a C-style cast of an lvalue will itself be 
> > treated as an lvalue under the following circumstances:
>
> Thanks for your description, but I find it incomplete.
>
> >   - The lvalue cast does not induce a type conversion (if it does, 
> > then we use the type conversion instead);
>
> You can't possibly mean this.  If the cast does not change the type, 
> then
> there's no reason to have it there.  Clearly some type conversions are
> permitted and some not -- please be specific about which.  May be
> you meant integral conversion, maybe you meant integral-pointer 
> conversions
> maybe you meant integral promotion ...

By "inducing a type conversion", I meant generating code to make the 
conversion happen, as in '(float)intValue'.  Perhaps I should have said 
'non-trivial type conversion' or some such.  In C, conversions among 
pointer types should always be trivial, but in C++, conversion 
operators could kick in.  In those non-trivial cases, we would disallow 
the lvalue cast.
> >   - The lvalue cast is being assigned to, incremented or decremented;
> ... or modified.  What is the bitrepresentation of the lvalue?  Is it
> that of the newly specified type, or is the static type of the 
> location?

Since we're talking about pointers, the bit representation does not 
change.  Microsoft also allows lvalue casts so long as the type being 
cast to is not larger than the original type (e.g., '(short)longValue' 
is OK whereas '(long)shortValue' is not); in those cases, I'm fairly 
certain
we want the bit layout of the newly specified type.

> >   - The lvalue is of a pointer type, and is being cast to a pointer 
> > type.
> ok, so this answers my questions about point 1. Any pointer type? Like
> the disallowed func->object conversion in C++? What about references
> and/or references to pointer types?  Does array/function->pointer
> decay occur? It might make sense to restrict the original lvalue
> type to 'void *'.

Just plain C pointers ('foo *', 'bar *'); no references and no 
pointers-to-members, although I see no reason why we should disallow 
arrays and function pointers.
> Are there any restrictions on the original lvalue that is being cast?

I don't understand this question -- what kind of restrictions 
could/should
there be?

> Is this extension composable? For instance what about the following,
> 	#define MAGIC_REGISTER ((void *)p)
> 	(int *)MAGIC_REGISTER += 2
>
> What about
> 	(expr, (int *)p) = something
> in C++?  In C++ operator, is an lvalue if its second operand is an
> lvalue. Similarly for ?:

I think the examples you give here should all work.
> Have you thought about specifying this in terms of a rewriting rule?

Under the conditions specified above,

         (foo)bar

could be rewritten to

         *((foo *)&bar)

> Do you have an analysis of interaction with existing features?

I don't, although I'm not sure what would constitute "analysis" in this 
context.
I suppose you can take the rewrite rule above and then try to see if 
the rewritten expression
would play nicely as an rvalue in other contexts; off the top of my 
head, I can't think of
situations where it would not, though I welcome others to poke holes in 
this theory.

One important thing to note is that the extension I'm proposing does 
not change existing, valid behavior; it only affects cases that 
currently (with TOT gcc 4.0) produce hard errors.

>  What
> programming errors would fall into this?

Are you asking, "how are programmers likely to misconstrue what this 
extension does"?  I think most programmers out there would probably be 
surprised that this is an extension at all, since most would expect 
something like

   (foo)bar = value;

to simply "work" :-); so probably the biggest pitfall would be that, 
even with the extension enabled, programmers will still get non-lvalue 
errors sometimes and then wonder why.

> Why do you want this extension?
> I see 6 different possible rationales. Are they all applicable?

Yes, they are all applicable, although any one of them taken separately 
is sufficient justification, IMO.  MS cnd CW compatibility is important 
because of code that is being brought over, but I don't think we 
necessarily have to implement each corner case of this extension as 
supported by these (and other) compilers (we could, but that would go 
way beyond what we are proposing here).  Rather, what we are concerned 
with is how the extensions tend to be used in real code.  And most 
existing usage, both in Apple's case and in examples cited by Michael 
Matz, has to do with pointer type manipulation.  So, even while I'm 
advocating this feature, I do not wish to bloat it unnecessarily.

--Zem