On 10/8/24 08:12, Jan Beulich wrote:
On 19.06.2024 16:01, Jan Beulich wrote:
Present wording has misled people to believe the ?: operator would be
evaluating all three of the involved expressions.
gcc/
* doc/extend.texi: Clarify __builtin_choose_expr() similarity to
the ?: operator.
Anyone? I don't think I can simply commit this as "trivial" - there's a
certain chance that I'm actually wrong here, after all.
Thanks, Jan
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14962,9 +14962,9 @@ struct {
This built-in function is analogous to the @samp{? :} operator in C,
except that the expression returned has its type unaltered by promotion
-rules. Also, the built-in function does not evaluate the expression
-that is not chosen. For example, if @var{const_exp} evaluates to @code{true},
-@var{exp2} is not evaluated even if it has side effects.
+rules. Like the @samp{? :} operator, the built-in function does not evaluate
+the expression that is not chosen. For example, if @var{const_exp} evaluates
+to @code{true}, @var{exp2} is not evaluated even if it has side effects.
This built-in function can return an lvalue if the chosen argument is an
lvalue.
Hmmm, looking at the complete documentation for this built-in, and the
code, I think I'd go a little farther with fixing up the docs.
Since requiring the first operand to be a constant is also different
behavior than the ?: operator, it's misleading to state only the return
type as being different. So I'd rewrite the whole paragraph quoted above:
Like the @samp{? :} operator, the built-in function does not evaluate
the expression that is not chosen. For example, if @var{const_exp}
evaluates
to @code{true}, @var{exp2} is not evaluated even if it has side effects.
On the other hand, @code{__builtin_choose_expr} differs from @samp{? :}
in that the first operand must be a compile-time constant, and the other
operands are not subject to the @samp{? :} type constraints and promotions.
-Sandra
