[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_C_NORETURN macro?
From: |
Vincent Lefevre |
Subject: |
Re: AC_C_NORETURN macro? |
Date: |
Thu, 26 Apr 2012 17:02:59 +0200 |
User-agent: |
Mutt/1.5.21-6201-vl-r48020 (2011-12-20) |
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 __.
> The whole point of gnulib is to give me enough support so that I can
> write code that is valid C11, and also which compiles under non-C11
> compilers, without any extra #ifdef work in my code (since gnulib
> took care of it for me).
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.
> > indeed some implementations may have another use of
> > "noreturn".
>
> 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.
> > but I don't see how it can be correct on a non-GCC non-SunPro C11
> > implementation: _Noreturn would get defined to nothing; the code
> > would be valid, but the C11 _Noreturn function specifier would not
> > be used.
>
> 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!
#ifndef _Noreturn
# if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
|| 0x5110 <= __SUNPRO_C)
# define _Noreturn __attribute__ ((__noreturn__))
# elif 1200 <= _MSC_VER
# define _Noreturn __declspec (noreturn)
# else
# define _Noreturn
# endif
#endif
--
Vincent Lefèvre <address@hidden> - 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)
- AC_C_NORETURN macro?, Vincent Lefevre, 2012/04/25
- Re: AC_C_NORETURN macro?, Eric Blake, 2012/04/25
- Re: AC_C_NORETURN macro?, Vincent Lefevre, 2012/04/26
- Re: AC_C_NORETURN macro?, Eric Blake, 2012/04/26
- Re: AC_C_NORETURN macro?,
Vincent Lefevre <=
- Re: AC_C_NORETURN macro?, Eric Blake, 2012/04/26
- Re: AC_C_NORETURN macro?, Vincent Lefevre, 2012/04/26
- Re: AC_C_NORETURN macro?, Nick Bowler, 2012/04/26
- Re: AC_C_NORETURN macro?, Vincent Lefevre, 2012/04/27
- Re: AC_C_NORETURN macro?, Russ Allbery, 2012/04/26
- Re: AC_C_NORETURN macro?, Vincent Lefevre, 2012/04/27
- Re: AC_C_NORETURN macro?, Paul Eggert, 2012/04/28
- Re: AC_C_NORETURN macro?, Bruno Haible, 2012/04/29
- Re: AC_C_NORETURN macro?, Vincent Lefevre, 2012/04/29
- Re: AC_C_NORETURN macro?, Bruno Haible, 2012/04/29