From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21436 invoked by alias); 16 Jul 2014 20:44:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 21394 invoked by uid 89); 16 Jul 2014 20:44:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f172.google.com X-Received: by 10.194.48.8 with SMTP id h8mr23084879wjn.106.1405543448018; Wed, 16 Jul 2014 13:44:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140716201505.34FF22C398F@topped-with-meat.com> References: <1405537923-28692-1-git-send-email-jim@meyering.net> <20140716201505.34FF22C398F@topped-with-meat.com> From: Jim Meyering Date: Wed, 16 Jul 2014 20:44:00 -0000 Message-ID: Subject: Re: [PATCH] assert.h: allow gcc to detect assert(a = 1) errors To: Roland McGrath Cc: libc-alpha@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2014-07/txt/msg00397.txt.bz2 On Wed, Jul 16, 2014 at 1:15 PM, Roland McGrath wrote: > This certainly should not go in during the current release freeze. > So you might not want to try to get too much discussion going until > the floodgates reopen. Also, various key people might be less than > usually responsive until after Cauldron (and for me, another week of > vacation thereafter). Thanks for the quick feedback. > Isn't there an "empty statement" warning that might be on too? We > certainly don't want the internals of the macro (the then clause in > your new version) to produce warnings of their own with any possible > combination of switches. -Wempty-body does not complain about the empty "then" clause inside that statement-expression. > You should be able to use __extension__ for GCC under -ansi. But > perhaps that would wrongly allow use of extensions inside the user's > expression too. If you're avoiding it for good reason, there should > be comments there explaining why. Good point. I confirmed that prefixing the ({... with __extension__ lets me eliminate the __STRICT_ANSI__ disjunct, and that -ansi still warns about a use like "assert( ({1}) );". I'll update the patch and repost here -- with a detailed test description -- in a couple weeks. > I also wonder how modern GCCs running in integrated preprocessor > mode deal with the system header exception and/or __extension__ for > this sort of case (since in integrated preprocessor mode it can tell > which part came from the system header and which from the user). > > Any change like this is going to need a lot of detailed reporting > about testing with different compilers and option combinations and > sorts of expressions (i.e. ones using extensions or not and perhaps > various different sorts of extensions). I've tested it with -Wextra -Wall -W -O, with uses as statements and as expressions. Also with and without -ansi. I have not yet tested with a non-__GNUC__ compiler, but will do. Thanks, Jim