[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 10:54:23 +0200 |
User-agent: |
Mutt/1.5.21-6201-vl-r48020 (2011-12-20) |
On 2012-04-25 10:24:19 -0600, Eric Blake wrote:
> Right now, gnulib already has not only such a macro, but also a
> <stdnoreturn.h> replacement header that supports this functionality for
> generic C11 compilers and older GCC, as well as working around a bug in
> MSVC vs. native Windows headers and their use of 'noreturn' in contexts
> that are incompatible with C11 usage. I'm not sure if it is worth
> trying to backport the gnulib work into upstream autoconf, or to just
> recommend that you use the gnulib solution up front (adding a macro,
> without also adding the code that exploits the macro, as gnulib does
> with its replacement <stdnoreturn.h> header, makes the macro harder to use).
The gnulib code, as I can see it under Debian, looks strange.
In lib/stdnoreturn.in.h:
#if 1200 <= _MSC_VER
/* Standard include files on this platform contain declarations like
"__declspec (noreturn) void abort (void);". "#define noreturn
_Noreturn" would cause this declaration to be rewritten to the
invalid "__declspec (__declspec (noreturn)) void abort (void);".
Instead, define noreturn to empty, so that such declarations are
rewritten to "__declspec () void abort (void);", which is
equivalent to "void abort (void);"; this gives up on noreturn's
advice to the compiler but at least it is valid code. */
# define noreturn /*empty*/
#else
# define noreturn _Noreturn
#endif
IMHO, the problem with _MSC_VER (which is not a bug, because
"noreturn" wasn't reserved) means that using the <stdnoreturn.h>
header is not the right solution for code that needs to be pre-C11
compatible; indeed some implementations may have another use of
"noreturn". I think there's also a clash with GCC's
__attribute__ ((noreturn))
if it is used by some depencency (e.g. GMP).
modules/snippet/_Noreturn references build-aux/snippet/_Noreturn.h,
which is:
#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
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.
I had changed the MPFR code to:
* Autoconf part:
dnl Check for _Noreturn function specifier (ISO C11)
AC_CACHE_CHECK([for _Noreturn], mpfr_cv_have_noreturn, [
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[_Noreturn void foo(int);]])],
mpfr_cv_have_noreturn=yes, mpfr_cv_have_noreturn=no)
])
if test "$mpfr_cv_have_noreturn" = "yes"; then
AC_DEFINE(MPFR_HAVE_NORETURN,1,[Define if the _Noreturn function specifier is
supported.])
fi
* The internal header part (mpfr-impl.h):
#if defined(MPFR_HAVE_NORETURN)
/* _Noreturn is specified by ISO C11 (Section 6.7.4);
in GCC, it is supported as of version 4.7. */
# define MPFR_NORETURN _Noreturn
#elif __MPFR_GNUC(3,0) || __MPFR_ICC(8,1,0)
# define MPFR_NORETURN __attribute__ ((noreturn))
#else
# define MPFR_NORETURN
#endif
I think that something like
#elif 1200 <= _MSC_VER
# define MPFR_NORETURN __declspec (noreturn)
could be added. And perhaps it would be better to add
&& !defined(noreturn)
for the GCC and MSVC cases.
--
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 <=
- 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?, 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