Re: AC_C_NORETURN macro?

[Vincent Lefevre]

On 2012-04-26 09:15:53 -0600, Eric Blake wrote:
> On 04/26/2012 09:02 AM, Vincent Lefevre wrote:
> > 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 __.
> 
> Any installed header that does not use the __ version is buggy.
> Thankfully, in the open source world, you can post bug reports and
> patches to get those buggy packages fixed;

This is an optimistic view.

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619933

(that's for the GCC documentation first).

Also, there's the problem that fixing old code may introduce new bugs.

> > 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.
> 
> Fair enough.  But then check directly for that feature, instead of
> asking gnulib to do it for you,

My original question was against autoconf (which already provides
macros for similar features), not gnulib.

> and feel free to use gnulib's checks as a starting point. And I'm
> still not convinced that we are ready to promote this into an
> autoconf macro quite yet; on the other hand, if we had someone
> working on improving the family of C macros to make it easier to
> tell C89, C99, and now C11 apart, as well as allowing packages to
> specify which flavor of language they are specifically targetting,
> then at that point, AC_C_NORETURN might make sense as a part of
> probing for C11.

Not really. Implementations (like GCC/glibc) may start to support C11
while they do not support C99 completely, e.g.

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

Autoconf should work on a feature basis, not on ISO C version
information (which is unreliable).

> >> 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.
> 
> Even when in --std=c99 mode?

No, but we want to be able to compile our code with --std=gnu99.
This is needed to get some extra (optional) features.

We have no problem with that, but this shows you that compilers are
not perfect.

> >> 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!
> 
> You missed an aspect - gnulib only provides a replacement
> <stdnoreturn.h> header on non-C11 systems; on systems where the system
> header is compliant, there is no need for gnulib to interject a
> replacement.  Therefore, under C11, gnulib is not defining anything away.

Ah, OK.

But I think that <stdnoreturn.h> is not a solution for MPFR, due to
the potential clashes with GMP (on which we depend), which uses GCC's
__attribute__ ((noreturn)). Though this may be fixed in the future,
problems would still appear with older versions. Thus we should use
_Noreturn directly, when supported.

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