On 2012-04-26 09:15:53 -0600, Eric Blake wrote: > On 04/26/2012 09:02 AM, Vincent Lefevre wrote: > > On 2012-04-26 08:14:51 -0600, Eric Blake wrote: > >> If I write C11 code: > >> > >> #include <stdnoreturn.h> > >> #include <stdio.h> > >> > >> then I expect things to work. But _MSC_VER system headers use noreturn > >> in a non-C11 manner, such that the only way for this to work via gnulib > >> is to make 'noreturn' a no-op on that platform, until such time as > >> Microsoft updates their headers. Microsoft has a history of namespace > >> pollution; had their compiler used '__declspec (__noreturn)' instead of > >> '__declspec (noreturn)', we would not be facing this clash. > > > > GCC has the same kind of problem. Though the __ version can also > > be used, it is poorly documented, and examples have the version > > without __. And some libraries under GNU/Linux reuse this version > > without __. > > Any installed header that does not use the __ version is buggy. > Thankfully, in the open source world, you can post bug reports and > patches to get those buggy packages fixed; This is an optimistic view. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619933 (that's for the GCC documentation first). Also, there's the problem that fixing old code may introduce new bugs. > > In MPFR, we want more: to be able to use the C99/C11 features and > > extensions from compilers (because the feature is not in the C > > standard or is too recent for the compilers). Not only the fact > > that the code compiles, but also that the feature is used. > > Fair enough. But then check directly for that feature, instead of > asking gnulib to do it for you, My original question was against autoconf (which already provides macros for similar features), not gnulib. > and feel free to use gnulib's checks as a starting point. And I'm > still not convinced that we are ready to promote this into an > autoconf macro quite yet; on the other hand, if we had someone > working on improving the family of C macros to make it easier to > tell C89, C99, and now C11 apart, as well as allowing packages to > specify which flavor of language they are specifically targetting, > then at that point, AC_C_NORETURN might make sense as a part of > probing for C11. Not really. Implementations (like GCC/glibc) may start to support C11 while they do not support C99 completely, e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Autoconf should work on a feature basis, not on ISO C version information (which is unreliable). > >> Not if they were compliant to C99 (since C99 didn't reserve 'noreturn', > >> then system headers under C99 mode should not be using that symbol). > > > > Almost no compilers/systems are compliant to C99. For instance, > > under Linux, GCC defines "unix" and "linux" to 1, while they are > > not reserved. > > Even when in --std=c99 mode? No, but we want to be able to compile our code with --std=gnu99. This is needed to get some extra (optional) features. We have no problem with that, but this shows you that compilers are not perfect. > >> Correct. _Noreturn is an optimization hint; your code will still > >> function correctly if the specifier is not present. The gnulib choice > >> to define it away on problematic systems is intentional. > > > > If I understand the gnulib code, gnulib defines it away also on pure > > C11 implementations (and not complete implementations that understand > > _Noreturn), which are not problematic systems! > > You missed an aspect - gnulib only provides a replacement > <stdnoreturn.h> header on non-C11 systems; on systems where the system > header is compliant, there is no need for gnulib to interject a > replacement. Therefore, under C11, gnulib is not defining anything away. Ah, OK. But I think that <stdnoreturn.h> is not a solution for MPFR, due to the potential clashes with GMP (on which we depend), which uses GCC's __attribute__ ((noreturn)). Though this may be fixed in the future, problems would still appear with older versions. Thus we should use _Noreturn directly, when supported. -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
