bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C99 inline and restrict keyword tests


From: Eric Blake
Subject: Re: C99 inline and restrict keyword tests
Date: Thu, 03 Dec 2009 05:53:11 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 12/2/2009 2:48 PM:
>>>> 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 :)
> 
> 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.

I'm not too enthusiastic about changing the macro behavior; so it seems
like improving the documentation to better describe the current situation
seems like the way to go.

>> 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.

Another instance of this is handling of 64-bit preprocessor constants.  At
one point, we tried to make long long checking fail if the preprocessor
also mishandled things, but in practice, there were enough existing
compilers that could do everything except preprocessing correctly that we
changed things to just document that AC_PROG_CC_C99 no longer guarantees a
compliant preprocessor, and that it is unportable to use any proprocessing
constant that requires more than 32 bits while expecting correct
signedness treatment.

>> 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.

Would either of you mind writing this up as a formal patch against
doc/autoconf.texi?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksXtLcACgkQ84KuGfSFAYDKcgCgtf1W9jXWxxx/qM2wWh00Cnai
k3gAoItu07rZ/4W328TeblAD2mBregtl
=uqr2
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]