On 06/04/2012 10:46 PM, Jason Merrill wrote:
On 06/04/2012 04:12 PM, Florian Weimer wrote:
This doesn't make sense to me. parser->integral_constant_expression_p
should always be true at this point if you're moving the restore later
(which also seems unnecessary).
I think parser->integral_constant_expression_p reflects the result of
the cp_parser_assignment_expression() call earlier in this function.
parser->integral_constant_expression_p is set to indicate that the
current context expects an integral constant expression; the call to
cp_parser_assignment_expression will not affect that.
If the expression turns out not to be a valid constant expression, then
we set parser->non_integral_constant_expression_p to true, but we don't
touch parser->integral_constant_expression_p.
Okay, now all this makes sense. This is a bit difficult to figure out
just reading the comments in cp/parser.h.
I think the condition you want is
if (parser->non_integral_constant_expression_p
&& !allow_non_constant_p)
True. But if we want cascading errors, cp_parser_constant_expression
really cannot return error_mark_node, so this approach is a dead end.
(For example, build_enumerator replaces error_mark_node in the
enumeration value with nothing, i.e., the next possible enumeration value.)
So this approach is a dead end. On the other hand, if cascading errors
are acceptable, I probably should not worry too much about them in
operator new, either. 8-)
--
Florian Weimer / Red Hat Product Security Team
