Re: generalized lvalues -- patch outline

[Nathan Sidwell <nathan at codesourcery dot com>]

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

>   - 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?
(I.e. what would a C interpreter that tracks dynamic type say about
that lvalue's 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 *'.

Are there any restrictions on the original lvalue that is being cast?
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 ?:

Have you thought about specifying this in terms of a rewriting rule?
Do you have an analysis of interaction with existing features? What
programming errors would fall into this?

>  (This will need to be relaxed somewhat should people desire
> Microsoft compatibility, at least for C.)
ahh, this leads me on to a rationale.  Why do you want this extension?
I see 6 different possible rationales. Are they all applicable?

1) Microsoft VC++ compatibility.  What are the specifications of this
extension?  (I see Matt is trying to find out.)  If this is the reason,
the whole of that extension should be implemented, and it should be enabled
on the existing -fms-extensions flag.

2) CodeWarrior compatibility. Same questions.  Is the CW extension exactly
the same as the VC++ extension?  There should be a -fcw-extensions flag
if we want to go down that route.

3) It is used in Apple's code base.  Mike Stump posted some numbers.  Can
you provide Apple's coding guidelines that document where this extension
can be used, and what the semantics are presumed to be?  I understand
the Linux kernel had some uses, but they have all been removed in the 2.6
series, because of their removal from gcc.  I have no idea on the relative
task sizes of removing it from Linux's and Apple's code base.

4) It is in use in other code that is 'out there'.  What code? Give
examples.  Given that one of the biggest bits (Linux kernel) has been
cleaned, this other code needs to be widely used and difficult to clean.
Andrew, what fraction of 3.4 bug reports concern this feature? (Does the
C FE give a deprecated warning, or are C users in the dark?)

5) Some ObjC/ObjC++ garbage collection proposal.  Other syntaxes have been
proposed.  I've not seen a detailed description of this proposal.

6) It leads to clearer, more understandable code.  It seems to me the
only thing that would be clearer is
	void *p = something;
	(int *)p += offset;
... maybe.  I do not find this compelling.  This code is what one finds
in memory allocators, and their implementation is few and far between.
In an allocator one would either make P a 'char *' or provide an inline
function/macro to do the adjustment.

I do not like the idea of special flags per extension.  That way lies
N^2 different 'interesting' failure modes.

nathan

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