Re: AC_C_NORETURN macro?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Vincent Lefevre wrote:
> 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.

If we get to know a different compiler which support _Noreturn but
does not have a working <stdnoreturn.h> file, we can add it to the
#ifs here.

> I had changed the MPFR code to:
> ...
> #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.

Sure. What you do here is reasonable. However, for gnulib the goal is
different: In programs that use gnulib we don't want to have the user
(developer) to learn new set of macros, different from what ISO C or
POSIX specify. Rather, we want the user to be able to use *exactly*
the syntax that is specified in ISO C or POSIX. And it happens that
the task of defining a MPFR_NORETURN macro that works like 'noreturn'
is an easier task than to define a 'noreturn' macro. The reason is that
with MSVC, the compiler wants to see   __declspec (noreturn)  but this is
hardly possible if 'noreturn' is at the same time defined as a macro without
arguments.

Bruno


_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf


[GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [USB]     [Samba]

Add to Google Powered by Linux