Le mardi 01 décembre 2009 à 19:25 +0100, Ralf Wildenhues a écrit : > Hello Yann, > > * 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 ? 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 ?. 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". Regards. -- Yann Droneaud
