bug-gnulib
[Top][All Lists]
Advanced

[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)



reply via email to

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