Re: Documentation bug for __builtin_choose_expr

[Jamie Lokier <jamie at shareable dot org>]

Andreas Schwab wrote:
> >      This built-in function is analogous to the `? :' 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 was not chosen.  For example, if CONST_EXP
> >      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      evaluates to true, EXP2 is not evaluated even if it has
> >      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      side-effects.
> >      ^^^^^^^^^^^^^
> >
> > The way this is written implies that the underscored behaviour is
> > different from the `? :' operator in C.
> 
> I don't see that.  For me the word "also" implies "another analogousness".

It depends how you parse it.

> IMHO this is fact is worth noting because the usual rules for function
> calls in C is to evaluate all its arguments first, whereas this builtin
> does not do that even though it uses a function-like notation.

I agree it's worth noting.  What do you think of the alternative wording
put forth by Joseph S. Myers, which I find clearer?  This is it:

     This built-in function is analogous to the `? :' operator in C,
     except that the expression returned has its type unaltered by
     promotion rules.  Unlike most built-in functions, but like the
     `? :' operator, this built-in function does not evaluate the
     expression that was not chosen.  For example, if CONST_EXP
     evaluates to true, EXP2 is not evaluated even if it has
     side-effects.

I can't check in the change, perhaps someone else can.

-- Jamie