Re: C99 inline and restrict keyword tests

[Ralf Wildenhues]

* Yann Droneaud wrote on Wed, Dec 02, 2009 at 10:32:26AM CET:
> Le mardi 01 décembre 2009 à 19:25 +0100, Ralf Wildenhues a écrit :
> > * Yann Droneaud wrote on Tue, Dec 01, 2009 at 03:09:11PM CET:
> > > If AC_PROG_CC_C99 successfully found a C99 compliant C compiler,
> > > AC_C_INLINE and AC_C_RESTRICT should use this result.
> > > 
> > > Testing for "inline" and "restrict" keywords is redundant,
> > > eg, checking ac_cv_prog_cc_c99 = yes should be enough.
> > 
> > Well, in theory you are right.  
> 
> Hey, autoconf is here to help developer to workaround reality and 
> stay in the theory nirvana :)

> > In practice, the restrict macro tries to
> > get a spelling that is likely to be accepted by the C++ compiler as
> > well, and the inline case checks for a specific compiler bug:
> > 
> > # HP C version B.11.11.04 doesn't allow a typedef as the return value for an
> > # inline function, only builtin types.
> > 
> > I can only check B.11.11.20, and it does not seem to have that bug (any
> > more).
> 
> Is HP C version B.11.11.04 found as C99 compatible by AC_PROG_CC_C99 ?

I'd guess not.  B.11.11.20 is not found as compatible with
  AC_INIT
  AC_PROG_CC_C99

due to:
  configure:2799: cc -AC99 -c -g  conftest.c >&5
  cc: "conftest.c", line 58: error 1671: Illegal use of restrict.
  configure:2806: $? = 1

but with
  AC_INIT
  AC_PROG_CC
  AC_C_RESTRICT
  AC_PROG_CC_C99

-AC99 will get turned on, and restrict #define'd to empty.  Hmm, not
very consistent, I guess.

> AC_PROG_CC_C99 use a test with one inline and one restrict, but not the
> corner case about typedef'ed type.
> 
> Should such compiler be rejected as C99 compliant C compiler ?.

This is somewhat of a judgement call.  If the bug is remote, then I
don't think that a general macro like AC_PROG_CC_C99 should reject the
compiler.  In practice that will harm more users than help, because it
will cause the necessary flag to enable C99 mode to not be used, which
would have been sufficient for the bulk of uses.

But in the end, this is the maintainer's call.  The documentation should
be updated in either outcome, to reflect the actual semantics of the
macros.

> IMHO, AC_PROG_CC_C99 and AC_C_INLINE + AC_C_RESTRICT should be related
> in some ways, perhaps AC_PROG_CC_C99 should rely on AC_C_INLINE +
> AC_C_RESTRICT ?
> In my first post, I was proposing the opposite: AC_C_INLINE +
> AC_C_RESTRICT relying of AC_PROG_CC_C99 result.
> 
> But the test stay like they are, if a note is added in AC_PROG_CC_C99,
> such as:
> 
> "AC_PROG_CC_C99 does not guarantee individual C99 features availability.
> Some compiler don't implement some or have buggy implementation, so one
> should use tests such as AC_C_INLINE, AC_C_RESTRICT, etc. in order to
> check C99 features they rely on".

This certainly would be one possibility.

Cheers,
Ralf