preprocessor, 'inline', and Apple's gcc

[Richard Guenther]

On Wed, 19 Mar 2008, David Monniaux wrote:

> Torbjorn Granlund wrote:
> > I take it that there are no problems unless you force the use of the
> > -std=c99 option?
> >   
> This is correct. APRON uses -std=c99
> > Why don't we ignore __GNU_STDC_INLINE__ and make decision solely on
> > __STDC_VERSION__ (when __GNUC__ is defined)?  That ought to simplify
> > the logics.
> When __GNUC__ is defined, we're either on gcc, either on patched versions of
> gcc including Apple's, or even on compilers claiming to behave like gcc (I
> think Intel's cc defines __GNUC__).

There is some context missing, I assume GMP headers use 'extern inline'
if __GNUC__ is defined.  As this is a gnu89 gcc extension that clashes
with C99 (which came after the fact), behavior was changed starting with
GCC 4.3.0 and it is advised to not use 'extern inline' in -std=c99
programs but instead use 'extern inline __attribute__((gnu_inline))'
if you want that semantics (that are not available with plain C99).

Otherwise using 'static inline' is most of the times a safe bet for
all compilers I know.

> For a while, gcc had a -std=c99 mode that did not turn on C99-compatible
> semantics for 'inline', yet defined  __STDC_VERSION__ to be 199901L- this is
> the case for gcc 4.1.2.

Right, you cannot rely on __STDC_VERSION__.  __GNU_STDC_INLINE__ is
what is recommended to check for 'inline' semantics.  If that
macro is defined then also the gnu_inline attribute is available.

> Are there any compilers out there, save for gcc, who both have non-standard
> semantics for inline yet define __STDC_VERSION__ to be 199901L?

I would expect so but don't know.

Richard.

-- 
Richard Guenther <rguenther at suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex