Re: localename: add support for musl libc

[Bruno Haible]

Hi Rich,

> Really use of NL_LOCALE_NAME should always be preferred if it's
> available, since it's a clean public interface for the functionality
> desired rather than a hack poking at implementation internals. But if
> you really like poking at internals for other implementations ...

In a perfect world, what you say would make sense.

However, not all libc versions that define _NL_LOCALE_NAME also have
a _NL_LOCALE_NAME that *works* [1]. It's not that I "really like poking
at internals". It's that I want my code to actually work.

> The comment /* musl */ above is wrong and should not have been added.

How can you judge that a comment in gnulib code is adequate, when you
are not familiar with the way gnulib is developed?

The comment /* musl */ says two things:
  - If a developer makes changes to these piece of code, they should
    test in on a system with musl libc.
  - If a developer sees that this code is being compiled/executed on
    a system without musl libc, they should review the #if chain, to
    make sure no mistake was introduced in #ifs.

Now back to my comment that you haven't addressed, regarding lack of
__MUSL__:

  If someone else
  creates a platform that shares the same superficial characteristics
  (runs on Linux, has <langinfo.h> and NL_LOCALE_NAME) but behaves
  differently, we will accidentally run into the code intended for musl
  on that platform. Whereas the fallback code (return "" in this case)
  would be safer: it would make the unit test fail, but it would not
  lead to a compilation error or to a code dump.

  And if that platform does not have an identifiying macro either, we
  really got a problem how to distinguish the two.

Bruno

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=10968