Finer-grained return values from bind_textdomain_codeset()

[orlitzky]

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.

[cmb69]

POSIX is pretty clear here:

If domainname is a null pointer, textdomain() shall return a pointer to the string containing the current text domain.

and

If domainname is a null pointer or an empty string, bindtextdomain() shall make no changes and return a null pointer without changing errno.

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]

POSIX is pretty clear here:

I'm only talking about bind_textdomain_codeset here, not bindtextdomain or textdomain. The two relevant paragraphs are,

If codeset is a null pointer and domainname is a non-empty string, bind_textdomain_codeset() shall return the current codeset for the named domain, or a null pointer if a codeset has not yet been set.

and

If bind_textdomain_codeset() fails, a null pointer shall be returned and errno shall be set to indicate the error.

musl is still a little bit weird in that it returns NULL rather 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]

Well, seems that #6631 had been done without much thinking; should have returned null (or maybe true) in this case.