Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA-4+jeUF8c+Kmv0UQi0akMAtc2hmi3pC_8=nBNcsfuRcjSgNA@mail.gmail.com>
Date: Fri, 1 Apr 2016 21:56:34 +0900
From: Masanori Ogino <masanori.ogino@...il.com>
To: bug-gnu-gettext@....org
Cc: musl@...ts.openwall.com
Subject: AM_GNU_GETTEXT without referring internal symbols?

Hello,

Now AM_GNU_GETTEXT uses _nl_msg_cat_cntr and _nl_expand_alias to check
whether the implementation is compatible with GNU gettext. However,
the symbols don't appear in libintl.h so it seems that they are not
part of the public API.

Actually, musl libc implements libintl features and the score of
gettext-tools' testsuite is equal to that with the internal libintl,
using a modified AM_GNU_GETTEXT.

The musl's libintl.h even defines __USE_GNU_GETTEXT and
__GNU_GETTEXT_SUPPORTED_REVISION, but it does not imitate private
symbols.

I had checked the archive and I've found some discussions:
https://lists.gnu.org/archive/html/bug-gnu-utils/2006-03/msg00011.html
http://lists.gnu.org/archive/html/bug-gettext/2015-11/msg00015.html

So, if the goal of the macro is check if the implementation is
compatible with GNU gettext, why don't we check the public API rather
than using internal symbols? Is it possible to check if the
implementation is not one of known "broken" implementations and/or it
is really compatible?

Regards,
-- 
Masanori Ogino

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.