Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3h9fit8lg.fsf-ueno@gnu.org>
Date: Mon, 04 Apr 2016 11:23:55 +0900
From: Daiki Ueno <ueno@....org>
To: Masanori Ogino <masanori.ogino@...il.com>
Cc: bug-gnu-gettext@....org,  musl@...ts.openwall.com
Subject: Re: [bug-gettext] AM_GNU_GETTEXT without referring internal symbols?

Hello,

Masanori Ogino <masanori.ogino@...il.com> writes:

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

I agree that it would be desirable, but doubt that it is possible (at
least reliably), because:

- For some reason, there is no public API to directly load arbitrary MO
  files and we need to mimic the behavior of translated applications:
  prepare a directory structure (e.g. DIR/fr/domain.mo), call
  bindtextdomain() for the directory, and finally call gettext().

- That requires that at least one non-POSIX locale is available on the
  system, to pick the translation.  However, even if the system is glibc
  based, not all locales might be available thanks to sub-packaging
  (Fedora) or user configuration (Debian).

So I suppose the only feasible option here is to somehow whitelist the
implementations by checking macros or symbols.  Does musl provides
anything like that[1]?

Regards,

Footnotes: 
[1]  https://sourceforge.net/p/predef/wiki/Libraries/

-- 
Daiki Ueno

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.