On Tue, 27 Nov 2018 10:49:56 -0800 Mike Stump <mikest...@comcast.net> wrote:
> On Nov 26, 2018, at 3:07 PM, Jozef Lawrynowicz <joze...@mittosystems.com> > wrote: > > > > It appears you can actually add __extension__ everywhere (that I tried), > > except > > for the argument types in the declaration of a function i.e. > > foo (__extension__ __SIZE_TYPE__ a) > > doesn't work. > > Ouch. Seems like a bug in the parsers. Could you file a bug report for this > against C and C++. Once that bug is fixed, then you can just add > __extension__ to SIZE_TYPE in your port file. Filed PR88237. > > > So I added __extension__ where possible, and in a couple of other cases I > > instead typedef'd with __extension__. > > > Ok for trunk? > > No. I mean, __extension__ should be added in SIZE_TYPE in your port.h file. > That, or, you need a type that won't complain when used. > > Recall, you're not doing the port for the testsuite, you're doing the port > for users. Users don't want a ton of warnings or errors when compiling > trivial standard code. Apologies, I made a mistake in the wording of my initial submission. intptr_t, size_t and ptrdiff_t do NOT cause errors, despite the base type being __int20. __INTPTR_TYPE__, __SIZE_TYPE__ and __PTRDIFF_TYPE__ DO cause the ISO C errors, as these are just macros which will expand to __int20 after pre-processing. The documentation says users should not use these __*_TYPE__ macros directly (cpp.texi): > You should not use these macros directly; instead, include the > appropriate headers and use the typedefs. Given that the errors only occur when using macros which expand to __int20, would you agree that the current behaviour of the compiler is correct? Thanks, Jozef
