From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23400 invoked by alias); 22 Nov 2004 13:19:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23349 invoked from network); 22 Nov 2004 13:19:47 -0000 Received: from unknown (HELO mail.shareable.org) (81.29.64.88) by sourceware.org with SMTP; 22 Nov 2004 13:19:47 -0000 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id iAMDJk81002982; Mon, 22 Nov 2004 13:19:46 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id iAMDJkfG002980; Mon, 22 Nov 2004 13:19:46 GMT Date: Mon, 22 Nov 2004 14:44:00 -0000 From: Jamie Lokier To: Andreas Schwab Cc: gcc@gcc.gnu.org Subject: Re: Documentation bug for __builtin_choose_expr Message-ID: <20041122131946.GA2893@mail.shareable.org> References: <20041122042652.GA26998@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2004-11/txt/msg00744.txt.bz2 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