bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 01/19] * m4/gnulib-common.m4 (gl_COMMON_BODY): Add _Noreturn.


From: Paul Eggert
Subject: Re: [PATCH 01/19] * m4/gnulib-common.m4 (gl_COMMON_BODY): Add _Noreturn.
Date: Mon, 11 Jul 2011 15:24:14 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11

On 07/11/11 15:15, Bruno Haible wrote:
> it looks to me that the ISO C and ISO C++ committees need to
> do some more work to align the syntaxes.

This is pretty unlikely.  They won't converge here,
just as they didn't converge with 'bool'.

The _Noreturn / <stdnoreturn.h> part of draft C1X has been present
in multiple drafts; I think it's reasonably safe to start tracking
it at this point.

> And on the gnulib side, either we should wait until the ISO C and ISO C++
> drafts have converged, or we should use _Noreturn everywhere and not
> use 'noreturn' (1. because of C++, 2. because of Microsoft's compiler).

My patch prefers _Noreturn when it can, for two reasons:

* In contexts like lib/stdlib.in.h, it reduces namespace pollution.

* It removes a dependency on the stdnoreturn module.

> In patches [14] to [18], you use noreturn.
> Which seems inconsistent.

Yes, this was in contexts like lib/openat.h.  Here, I was
worried about the case where openat.h is copied elsewhere and
is used by a random compiler, not necessarily the compiler that
'configure' was run with.  In that case, it's safer for
the code to include <stdnoreturn.h>, which should be in the
same include path.  However, if these files (namely, openat.h,
sigpipe-die.h, xalloc.h, xmemdup0.h, xstrtol.h) are not intended
to be copied elsewhere, it'd be better to be consistent and to
have them use _Noreturn as well; that way, their modules wouldn't
need to depend on the stdnoreturn module.



reply via email to

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