Re: generalized lvalues -- patch outline

[Nathan Sidwell <nathan@codesourcery.com>]

Ziemowit Laski wrote:

> 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.

Ok, so whether this extension is applicable is implementation defined,
based on the sizes of the supported data types.  C and C++ standards
do not currently have such conditionally defined behaviour (although there
are moves to define such a term in C++ at least).

>>>   - 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.

This is an implementation assumption.  Some machines have different
bit representations for char * and int * pointers for instance (do
we support them, I don't know).  So, this is another implementation
restriction.

>  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.

so (short)longValue should not touch longValue's bits outside of a
short?  But I thought you were restricting to casts between object pointer
types, so why is this relevent?

>>>   - 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.

so '(foo *)ary' is permitted?

>> 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?

I don't know.  you tell me, you're the one specifying this extension

> 
>> 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.
do you mean that these examples must be accepted by the extension?
AFAICT the first one (int *)(void *)p does not as currently specified,
because (void *)p is not an lvalue cast as it's not being assigned to
or modified. If these are to be accepted, something is lacking in the
specification.

>> 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)

this rewriting rule falls foul of the type based aliasing rules.

>> 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.

Well, consider all the existing language features and show how they are
either unaffected, or the changes are not detrimental.

> 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.

I showed your rewriting rules break existing optimizations (or other
ways around, existing optimizations will cause your rewriting rule to
generate code that does not do what your extension claims to do). I find
'off the top of my head' to be an unsatisfactory way of defining language
extensions.

> 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 am asking what currently rejected programs that *really* are
programming errors, would silently be accepted, and then lead to hard
to debug problems.

> 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.

I beg to differ.  I have no data on what 'most' C programmers think about
bits of code that are not specified in the C standard, or any book
that teaches standard C or in the gcc documentation.  How have you
determined what 'most' programmers think about this?

>> 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).

What code is being brought over?  If compatibility is important, what
are the specifications of MS's and CW's extensions.  It appears this
information is being gathered.  It would be useless to implement a
partial extension, if the main use in the ported code was a different
bit of the extension.


>  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.

 From this I understand that the use in Apple's code is accidental, as
you've not shown the coding guidelines.

You've not followed up on the ObjC rationale.  Is that an issue or
not?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk