Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Apr 2016 11:26:53 +0900
From: Daiki Ueno <>
To: Masanori Ogino <>
Subject: Re: Re: [bug-gettext] AM_GNU_GETTEXT without referring internal symbols?

Masanori Ogino <> writes:

>> 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]?
> No, it doesn't on purpose. Here is the entry on this topic in the FAQ:
> Also, I'd like to point out some detailed explanations in a recent discussion:

Thanks for the information.

> That is why I proposed to have a blacklist of "broken" implementations
> as an option.
> AFAIK there have already been some blacklisting in autotools e.g.
> checking the version of glibc to reject specific broken implementation
> of a function. Thus, I think it's acceptable to use a blacklist. What
> do you think about it?

Yes, that sounds like a good idea.  But I guess we then need to collect
information about incompatible implementations.  In this regard I'm
actually not sure if the gettext-tools test coverage can be used as an
indicator of compatibility.

By the way, musl defines __GNU_GETTEXT_SUPPORTED_REVISION in the same
way as glibc:

  #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 1 : -1)

Is major = 1 + minor = 1 actually supported in musl?

After briefly checking Solaris 11 variants have:

          ((((m) == 0) || ((m) == 1)) ? 1 : -1)

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.