This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: generalized lvalues


On Fri, 19 Nov 2004, Ziemowit Laski wrote:

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

The removal of cast-as-lvalue got rid of a lot of crufty code.  Bringing 
it back under a conditional is not a good idea.  For your ObjC uses, you 
don't want to allow assignments to casts in general - only to some 
ObjC-specific constructs, which might or might not be syntactically casts 
to ObjC-specific types.  I'd suggest detecting whatever construct (whether 
or not expressed as a cast in the syntax) and representing it as an 
ObjC-specific tree code, which acts as an lvalue and has whatever other 
magic semantics are required and is lowered in gimplification - not as 
NOP_EXPR/CONVERT_EXPR.  The construct in question should only be able to 
occur in ObjC and ObjC++ code, not plain C or C++.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]