From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5530 invoked by alias); 5 Jun 2019 22:12:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5522 invoked by uid 89); 5 Jun 2019 22:12:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=grammar X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Jun 2019 22:12:27 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x55MCPQo024675; Wed, 5 Jun 2019 17:12:25 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x55MCPue024667; Wed, 5 Jun 2019 17:12:25 -0500 Date: Wed, 05 Jun 2019 22:12:00 -0000 From: Segher Boessenkool To: Jozef Lawrynowicz Cc: gcc@gcc.gnu.org Subject: Re: Preventing ISO C errors when using macros for builtin types Message-ID: <20190605221225.GV31586@gate.crashing.org> References: <20190605142559.05791323@jozef-kubuntu> <20190605164921.GT31586@gate.crashing.org> <20190605204939.4d580841@jozef-kubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190605204939.4d580841@jozef-kubuntu> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00034.txt.bz2 On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote: > On Wed, 5 Jun 2019 11:49:21 -0500 > Segher Boessenkool wrote: > > The documentation says > > > > '-pedantic' and other options cause warnings for many GNU C extensions. > > You can prevent such warnings within one expression by writing > > '__extension__' before the expression. '__extension__' has no effect > > aside from this. > > > > It's not clear to me why you cannot simply put __extension__ earlier in > > your case? > > If I am modifying tests on an individual basis, then indeed I can put > __extension__ earlier in the declaration and it fixes the issue. Or you could fix it like this in your header file? > But for a fix within the compiler to prevent having to modify individual tests, > I could add __extension__ to the beginning of the macro - but the macro may > not end up at the beginning of a declaration in the source code. > > For example, say __SIZE_TYPE__ now expands to "__extension__ __int20 unsigned", > then the following usage of __SIZE_TYPE__ would be ok, as __extension__ is at > the beginning of the declaration: > > > __SIZE_TYPE__ size; Don't use macros for types? You could use something like __extension__ typedef unsigned __int20 __SIZE_TYPE__; (stddef.h already uses typedefs like that, btw, for __SIZE_TYPE__ in fact). > I'm mainly just wondering if a change to the compiler to allow the usage of > __extension__ within a declaration would be allowed. Well, how would that work? We'd need to modify the grammar to allow __extension__ pretty much anywhere, and then change all compiler code to not pedwarn until it has parsed a full expression (or statement, or file, or however this will work). Or make it not warn for things after the __extension__ only, or make it only *guaranteed* not to warn for things *after* the __extension__. None of those options are very appetising, IMO. Segher