[Top][All Lists]

[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

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)

reply via email to

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