On 08.10.2024 17:30, Sandra Loosemore wrote:
> 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.

Fine with me; I assume you will then simply put in your version of the
change?

Jan

Reply via email to