Re: C++ PATCH: Bug in ?: operator

[Jason Merrill <jason at cygnus dot com>]

>>>>> Mark Mitchell <mark@codesourcery.com> writes:

 > But the expression `*vp += 2' doesn't have type `volatile foo&'.  It is
 > an lvalue of type `volatile foo'.  No expressions have type `T&' for
 > any `T'; the reference decays immediately.

 >   [expr]

 >   If an expression initially has the type "reference to T" (_dcl.ref_,
 >   _dcl.init.ref_), the type is adjusted to T" prior to any further anal-
 >   ysis,  the expression designates the object or function denoted by the
 >   reference, and the expression is an lvalue.

Sure.  I've basically considered references to be shorthand for passing
around lvalues.

 > But, I think that's all an aside.  The case you give (`*vp += 2')
 > doesn't seem to trigger the code in cplus_expand_expr_stmt you refer
 > to.  I guess I'm misunderstanding your train of thought.

I was thinking of the builtin prototypes for operators, which return
references.  But it would trigger the code in question if *vp were of
appropriate class type.

 > That code does fire on `vr;' if `vr' is a `volatile int&'.  On the one
 > hand it makes sense to treat this essentially similarly to `vp;';
 > references are just pointers that don't need a `*'.  On the other
 > hand, this gives the C++ programmer with a reference no way to do the
 > equivalent of what the C programmer did with a pointer, unless she
 > writes the appalling `*&vr'.  I'm not sure what to think.

I think that's fine.  Anyone who uses a reference for interacting with an
I/O port should be shot anyway.

 > Bottom line: casts to void never make a difference.

Agreed.  Unless we want to define them differently for volatile lvalues,
but I don't.

 > We should break out the code in cplus_expand_expr_stmt, and call it
 > from all the "void contexts": first expression in a comma-expression,
 > cast to void, expression statement.

Agreed.

 > That just leaves us with what to put in the broken-out code, i.e.,
 > what to do about the volatile semantics.

 > Concretely, I think:

 >   o require_complete_type_in_void should be removed.
 >   o a new function, to deal with the semantics of volatile in 
 >     void contexts should be written.  It should probably do what
 >     cplus_expand_expr_stmt does now; strip INDIRECT_REFs off
 >     references, and leave everything else alone.
 >   o that function should be called to transform an expression in a
 >     void context.

Works for me.

Jason