This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Preventing ISO C errors when using macros for builtin types
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jozef Lawrynowicz <jozefl dot gcc at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 5 Jun 2019 17:12:25 -0500
- Subject: Re: Preventing ISO C errors when using macros for builtin types
- References: <20190605142559.05791323@jozef-kubuntu> <20190605164921.GT31586@gate.crashing.org> <20190605204939.4d580841@jozef-kubuntu>
On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> On Wed, 5 Jun 2019 11:49:21 -0500
> Segher Boessenkool <segher@kernel.crashing.org> 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