Re: cvs: php-src(PHP_5_3) /ext/mbstring mbstring.c
| From: | Moriyoshi Koizumi | Date: | Sat, 13 Sep 2008 19:39:42 +0000 |
| Subject: | Re: cvs: php-src(PHP_5_3) /ext/mbstring mbstring.c | ||
| References: | 1 2 3 4 | Groups: | php.cvs |
| Request: | Send a blank email to php-cvs+get-53120@lists.php.net to get a copy of this message | ||
Hi Antony,
It seems I mistook what you addressed. I thought you were talking about
the situation with per-dir settings because you mentioned it as
PHP_INI_SYSTEM, though, as you said, I failed to think of the runtime
settings.
I guess adding (stage == PHP_INI_STAGE_RUNTIME) in the conditions will
fix the problem.
Moriyoshi
Antony Dovgal wrote:
> On 12.09.2008 23:09, Moriyoshi Koizumi wrote:
>> Hi Antony,
>>
>> Antony Dovgal wrote:
>>> The docs say mbstring.internal_encoding is PHP_INI_ALL, but this change
>>> makes it in fact PHP_INI_SYSTEM.
>>> Also why allow using mb_internal_encoding() and disallow changing the
>>> ini setting?
>>
>> I missed your mail. Sorry for the late reply.
>>
>> As for your question. It's not really an INI_SYSTEM setting.
>
> But you can't change it with ini_set() once the request is started,
> therefore it's not INI_ALL anymore.
>
>> To take
>> account of the other settings that are affected by the value of
>> mbstring.internal_encoding, it turned out the corresponding global entry
>> got to be handled in RINIT. the original INI values are kept by the
>> zend_ini facility separately, so doing so is anyway safe.
>
> That doesn't answer my question.
> We have mb_internal_encoding(), which updates internal encoding;
> and we have ini_set() which is supposed to do the same, but it fails
> after your patch.
>
> What was the reason for such changes (breaking BC and such..) and what's
> the point to keep calling it INI_ALL if you can't change it with
> ini_set() anymore?
>