bug-gettext
[Top][All Lists]
Advanced

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

Re: [bug-gettext] [PATCH] gettext-runtime/intl: Merge from glibc


From: Daiki Ueno
Subject: Re: [bug-gettext] [PATCH] gettext-runtime/intl: Merge from glibc
Date: Sat, 13 Dec 2014 12:15:37 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Will Newton <address@hidden> writes:

>>> -#if defined _LIBC_REENTRANT || HAVE_DECL_FGETS_UNLOCKED
>>> +#if defined _LIBC_REENTRANT || defined HAVE_DECL_FGETS_UNLOCKED
>>
>> This is no-no.  On some platforms (e.g. Mac OS X),
>> HAVE_DECL_FGETS_UNLOCKED will be defined as 0:
>>
>>   $ grep 'define HAVE_DECL_FGETS' gettext-runtime/config.h
>>   #define HAVE_DECL_FGETS_UNLOCKED 0
>>
>> What's the rationale behind this change?  According to C99 and C11, the
>> C preprocessor shall convert undefined identifiers to pp-number 0 before
>> evaluation.
>
> glibc quite recently switched to passing -Wundef to the compiler which
> requires that #if is only used on defined values in order to catch
> bugs where somebody forgets or typos the name of a define.

Ah, I just remembered the related discussion on bug-gnulib.

> The usual way of testing config variables that start with HAVE_ is to
> use #ifdef as they are binary on/off switches. Is there a reason this
> constant must distinguish between not-defined and zero?

It is an expansion of a standard autoconf macro AC_CHECK_DECLS and is
a documented behavior:
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Generic-Declarations.html#index-AC_005fCHECK_005fDECLS-680

Perhaps we could special case this in intl/, but it would be non-trivial
and I doubt that it is worth doing just in order to suppress the
compiler warnings.  So, IMO,

> Converting it to:
>
> #if defined _LIBC_REENTRANT || (defined HAVE_DECL_FGETS_UNLOCKED &&
> HAVE_DECL_FGETS_UNLOCKED)
>
> should work but it is a bit ugly.

This is the easier way to work around it (and it seems argp/ already
does that).

Regards,
-- 
Daiki Ueno



reply via email to

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