https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46073
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Joseph S. Myers from comment #5)
> It's doubtful that this is a bug. You could define __builtin_choose_expr so
> the unselected operand only needs to be a balanced token sequence (with no
> commas unless nested inside () [] {}), but it's less clear that you should;
> there are disadvantages to not checking unselected operands as well as
> advantages. (Cf. how it's often better to use if () rather than #if for
> conditionals on compile-time constants so that more of the syntax gets
> checked in all build configurations.)
in the current documentation of __builtin_choose_expr
(https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html), it's clearly
specified:
"... Also, the built-in function does not evaluate the expression that is not
chosen. For example, if const_exp evaluates to true, exp2 is not evaluated even
if it has side effects.
...
Note: ... the unused expression (exp1 or exp2 depending on the value of
const_exp) may still generate syntax errors. This may change in future
revisions."
My understanding of the above statements is: The unused expression should not
be evaluated and also should not generate syntax errors, this is a current
limitation of this builtin, and will be changed in future releases.
is this understanding correct?
> (Technically, some valid code could change its semantics if you start
> treating one half as only a balanced token sequence - struct / union / enum
> types defined inside the unselected expression would no longer get declared
> for the rest of the scope
A little confused here: Due to the documentation, the unselected expression
should not be evaluated, as a result, the definitions inside the unselected
expression should NOT be declared either. A program depends on the definition
inside the unselected expression is expecting unexpected behavior.
Do you know any application currently depends on definitions inside the
unselected expression?
- but I think that could safely be ignored, just
> included in the tests added, if we decide to make such a change.)
