Re: AC_C_NORETURN macro?

[Eric Blake]

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; which is a much different
story than for the proprietary _MSC_VER system headers.

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

Fair enough.  But then check directly for that feature, instead of
asking gnulib to do it for you, 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 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?  I can understand this in --std=gnu99 mode
(since gnu99 explicitly allows extensions).  This particular pollution
is rather pervasive due to historical practice, but if it bothers you
that much, I'm sure you could file a bug report, and that someone
working on gcc or glibc might be willing to help you address it.

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

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature