On Thu, Dec 23, 2021 at 5:32 AM Christoph M. Becker wrote:
>
> On 22.12.2021 at 22:44, Jakub Zelenka wrote:
>
> > After thinking about this a bit more I think we would still need some way
> > to provide the current functionality of the MINIT if that's moved on child
> > level. The problem with
On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker
wrote:
> Hi all,
>
> a while ago it has been reported[1] that our header() function actually
> allows arbitrary status codes, which may even overflow. Of course, that
> makes no sense, since the status code is supposed to be a three digit
>
On 21.12.2021 at 20:09, Ayesh Karunaratne wrote:
>> a while ago it has been reported[1] that our header() function actually
>> allows arbitrary status codes, which may even overflow. Of course, that
>> makes no sense, since the status code is supposed to be a three digit
>> code. So this ticket
On 22.12.2021 at 22:44, Jakub Zelenka wrote:
> After thinking about this a bit more I think we would still need some way
> to provide the current functionality of the MINIT if that's moved on child
> level. The problem with not having such step is that opcache shm would be
> then segmented
>
>> My suggestion for a fix would be to emulate what Apache always did:
>>
>> One MINIT/MSHUTDOWN in the main control process (I think it needed that
>> to be able to implement php_admin_value and php_value), and then
>> additionally also in each worker process.
>>
>
> As I said above, it won't
On 22/12/2021 14:45, Hans Henrik Bergan wrote:
I wonder if anyone depends on utf8_* without also depending on mb_* ? I
imagine that is exceedingly rare
On the contrary, anyone who uses mb_* functions is likely to use
mb_convert_encoding rather than utf8_encode and utf8_decode.
In fact, the
On Wed, Dec 22, 2021 at 1:39 AM Hassan Ahmed <7sno...@gmail.com> wrote:
> Hello Levi, maybe, I just was confused while I was rewriting it. any tips
> would be appreciated.
>
There's a lot of information about this that is missing from the RFC. It
says it "will be overwritten". Does that mean
I wonder if anyone depends on utf8_* without also depending on mb_* ? I
imagine that is exceedingly rare
On Wed, Dec 22, 2021, 15:26 Rowan Tommins wrote:
> On 22/12/2021 10:45, Andreas Heigl wrote:
> > I just dug a bit deeper on the subject and found this RFC from 2016:
> >
> >
On 22/12/2021 10:45, Andreas Heigl wrote:
I just dug a bit deeper on the subject and found this RFC from 2016:
https://wiki.php.net/rfc/remove_utf_8_decode_encode
Perhaps we can just revive that one!
As I say, I have a draft with lots more detail in, which I will tidy up
after Christmas.
Hey All.
On 22.12.21 10:08, Andreas Heigl wrote:
Hey all.
On 22.12.21 10:00, Rowan Tommins wrote:
[...]
On 22/12/2021 00:31, Kris Craig wrote:
Now might be a good time to make this into an RFC. :)
I have a draft kicking around with a lot of analysis of current usage.
I will try to
Hello Levi, maybe, I just was confused while I was rewriting it. any tips
would be appreciated.
On Tue, Dec 21, 2021 at 5:58 PM Levi Morrison
wrote:
> On Tue, Dec 21, 2021 at 1:48 AM Hassan Ahmed <7sno...@gmail.com> wrote:
> >
> > Hello all,
> >
> > I would like to start a voting phase for this
Hey all.
On 22.12.21 10:00, Rowan Tommins wrote:
On 21/12/2021 23:20, Wade Rossmann wrote:
I would suggest adding optional source/destination encoding parameters to
the functions, eg:
utf8_encode(string $string, string $source_encoding = "ISO-8859-1")
utf8_decode(string $string, string
On 21/12/2021 23:20, Wade Rossmann wrote:
I would suggest adding optional source/destination encoding parameters to
the functions, eg:
utf8_encode(string $string, string $source_encoding = "ISO-8859-1")
utf8_decode(string $string, string $destination_encoding = "ISO-8859-1")
That's an
13 matches
Mail list logo
