[Top][All Lists]
[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.
Re: [PATCH 01/19] * m4/gnulib-common.m4 (gl_COMMON_BODY): Add _Noreturn., Ben Pfaff, 2011/07/11