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
