Repository navigation
Finer-grained return values from bind_textdomain_codeset() #17163
Description
Description
As mentioned in php/doc-en#4311, the bind_textdomain_codeset() function returns false in some "success" cases because it is only looking at the NULL returned from the C function. But that NULL is not necessarily an error, it just means that the codeset has not changed from the default. In particular, you'll get a NULL from glibc if you query a codeset that hasn't been set yet, and you'll always get NULL on musl.
According to https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/bind_textdomain_codeset.html, the value of errno may be a better indicator:
If bind_textdomain_codeset() fails, a null pointer shall be returned and errno shall be set to indicate the error.
Edit: as of musl-1.2.6, a NULL is returned only when the codeset is not "UTF-8" (https://git.musl-libc.org/cgit/musl/commit/src/locale/bind_textdomain_codeset.c?id=cabbd8697d39c09ca37fb3d63b86b42526b81fda)
Activity
cmb69 commentedon Dec 15, 2024
POSIX is pretty clear here:
and
If musl (or any other implementation) return NULL here, they are not conforming to the specification. And that errno is unchanged, is to be expected. What is PHP supposed to do? Just say "yeah, the call was successful" would be wrong.
orlitzky commentedon Dec 15, 2024
I'm only talking about bind_textdomain_codeset here, not
bindtextdomainortextdomain. The two relevant paragraphs are,and
musl is still a little bit weird in that it returns
NULLrather than"UTF-8"on successive calls, but if you are handling the case where the codeset has not yet been set (which affects glibc, too), then you'll do the right thing on musl too.cmb69 commentedon Dec 15, 2024
Well, seems that #6631 had been done without much thinking; should have returned
null(or maybetrue) in this case.ext/gettext/tests: fix libintl return values under musl