Bug #53251 [Opn]: bindtextdomain with null directory doesn't return the previously set

Edit report at https://bugs.php.net/bug.php?id=53251&edit=1 ID: 53251 Updated by: cmb@php.net Reported by: jeanseb at au-fil-du dot net Summary: bindtextdomain with null directory doesn't return the previously set Status: Open Type: Bug Package: Gettext related Operating System: Debian 5.0.6 PHP Version: 5.3.3 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: The basic problem here is that neither bindtextdomain() nor bind_textdomain_codeset() (the PHP functions) do actually accept null for $directory and $codeset, respectively. An empty string is not null, and should not be treated as such, because the respective C function also clearly distinguish between both. bindtextdomain($domain, "") *binds* the textdomain to the VCWD, while bindtextdomain($domain, NULL) is supposed to return the bound directory. Anyhow, the actual blocker for this bug fix was apparently the discussion around the virtual CWD issues, which I do not really understand. If PHP's bindtextdomain() has been called to bind a directory, that already was "corrected" by calling VCWD_REALPATH() and as such is an absolute path. If PHP's bindtextdomain() has not yet been called, we should return bindtextdomain(3)'s return value unmodified. Previous Comments: ------------------------------------------------------------------------ [2019-04-02 23:50:24] c dot madmax at gmail dot com I can confirm that this bug still exists, 9 years after it was reported! bind_textdomain_codeset() also returns a wrong result if the codeset argument is set to null. Only textdomain() is correct implemented and can be used to query the current setting. The necessary changes in the source code are trivial, why does it take a decade to fix this? The linux man pages clearly say: "If dirname is NULL, the function returns the previously set base directory for domain domainname." Source: https://linux.die.net/man/3/bindtextdomain "If codeset is NULL, the function returns the previously set codeset for domain domainname. The default is NULL, denoting the locale's character encoding." Source: http://man7.org/linux/man-pages/man3/bind_textdomain_codeset.3.html ------------------------------------------------------------------------ [2011-09-26 23:55:26] tyrael@php.net what is missing here to move forward with the fix? Tyrael ------------------------------------------------------------------------ [2010-11-26 23:12:03] greno at verizon dot net Please, I do read and consider all of your comments. And I understand the concern about the TS build. I was merely trying to convey that I have not seen or read about any evidence that is convincing that using gettext in threads would be successful given the current state of the underlying GNU gettext library. I based this on things like this: Checking latest gettext manual here: http://www.gnu.org/software/gettext/manual/gettext.html#PHP It shows that PHP 'uses' not 'emulates' the GNU underlying gettext library. The GNU library is not thread-safe. Checking PHP gettext in the manual: http://www.php.net/manual/en/gettext.requirements.php It shows a comment stating that PHP gettext is not thread-safe and even gives an example of one of the environment variables that can drive the underlying GNU gettext library. The comment supports other places of information that basically assert the same thing. I certainly agree, if you need to put some type of ifdef TSMODE or whatever in the patch OK, please by all means put it in there. That only would apply to the threaded model so it would be a NOP to those using the non-threaded model. If you need to force the fact that the bound directory must exist for whatever reason in the threaded model, OK, that's some limitation of the threaded model. It deviates from the defined GNU bindtextdomain behavior but to get a threaded model working maybe that's a necessary tradeoff. My only goal is to get a patch in PHP 5.2 and 5.3 asap to fix the current brokenness of bindtextdomain. . ------------------------------------------------------------------------ [2010-11-26 21:03:57] pajoye@php.net I really appreciate your feedback but it tends to be a monologue. You totally ignore any comment you disagree with or don't care about. I explained already many times why and when we should care about that. I even pointed to the gettext documentation telling that. So let say that unless you have something new to say, the problem is identified and will be fixed asap. ------------------------------------------------------------------------ [2010-11-26 20:51:39] greno at verizon dot net Gettext is not thread-safe. You shouldn't need to worry about trying to get gettext working in threads. The underlying gettext library would first have to be made thread-safe and no longer able to be driven by environment variables. Gettext can be driven by environment variables and unless you have a way to set up completely different environments for each thread, then there is never going to be a way to reliably use gettext in threads. One thread could set an env var to one value and another thread in the same process set the env var to a different value and both of these threads would see the value set by the latest thread. And gettext would behave according to the latest setting which would totally screw up the earlier thread. . ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53251 -- Edit this bug report at https://bugs.php.net/bug.php?id=53251&edit=1