On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote: > On Wed, 5 Jun 2019 11:49:21 -0500 > Segher Boessenkool <seg...@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
