On 11 August 2024 16:50:52 BST, Nick Lockheart wrote:
>It seems that if everything on the Internet is multi-byte encoded now,
>then all of the PHP string functions should be multi-byte safe.
The phrase "multibyte safe" may have made sense about 30 years ago, when it was
thought that a "univer
On 12/08/2024 00:36, Nick Lockheart wrote:
So what I would propose is:
(1) All string functions should state in the official man page if they
are safe for UTF-8 or not.
Reasonable but see below
(2) Functions intended for working with text should be made UTF-8 safe.
Define precisely UTF-8 s
Hello,
I’m considering adding some C++ enhancements to the Zend API. These changes
would be encapsulated within `#ifdef __cplusplus` guards, so they wouldn’t
interfere with the existing C implementation. The primary goal is to
provide a nicer interface for extensions while maintaining compatibilit
> There's a lot of pitfalls here, and I don't think the documentation
> clearly calls out which functions are OK to use with UTF-8 and which
> ones may cause unexpected surprises.
>
> The compatibility between ASCII and UTF-8 for Latin characters is both
> a curse and a blessing. An application may
On 11.08.2024 at 22:21, Juliette Reinders Folmer wrote:
> Thanks Christoph! I was tempted to update the RFCs myself, but thought
> it was against protocol for anyone but the RFC owner to do so ? hence my
> email.
Changing an open RFC without consent of the RFC author(s) is certainly
against proto
Hello,
I’m considering adding some C++ enhancements to the Zend API. These changes
would be encapsulated within `#ifdef __cplusplus` guards, so they wouldn’t
interfere with the existing C implementation. The primary goal is to
provide a nicer interface for extensions while maintaining compatibilit
>
>
> Some background and history, for those not familiar...
>
> After PHP 5.2, there was a huge effort to move PHP to using Unicode
> internally. It was to be released as PHP 6. Unfortunately, it ran
> into a whole host of problems, among them:
>
> 1. It tried to use UTF-16 internally, as th
Thank you, Juliette. I added missing information to my RFC: Raising zero to
the power of negative number.
Kind regards,
Jorg
On 11-8-2024 18:55, Christoph M. Becker wrote:
On 11.08.2024 at 08:05, Juliette Reinders Folmer wrote:
I'm currently going through the RFC wiki page and I'm seeing various
(PHP 8.4) RFCs which haven't been properly updated after the vote.
I've not gone through all of the RFCs, but these are d
On Aug 11, 2024, at 10:22 AM, Marco Aurélio Deleu wrote:
> On 11 Aug 2024, at 13:59, Christoph M. Becker wrote:
>>
>> On a general note, the whole administrative part of the RFC process
>> feels like we're stuck in the 20th century. For instance, to start the
>> vote, you are supposed to:
>>
>
On Mon, Aug 12, 2024 at 02:03:08AM +0900, youkidearitai wrote:
> 2024年8月12日(月) 1:42 Anton Smirnov :
> I'm confused what is "multibyte safe".
I think that he means that the bytes are only valid UTF-8 sequences.
This would mean that some byte sequences would not be allowed.
-1 to this idea.
--
On 11/08/2024 17:56, Lanre wrote:
On Sun, Aug 11, 2024 at 9:23 AM Nick Lockheart
wrote:
Seriously, Don't give up.
readonly properties were declined in 2014. It's now part of PHP.
There's many other examples like that.
Sometimes you just need to beat the dead horse until it
On 11.08.2024 at 19:06, Ayesh Karunaratne wrote:
>> I've fixed up the first two, but I haven't yet found the PRs regarding
>> the extension unbundling [snip]
>
> I'm watching the php-src repo for some writing stuff and noted down the
> commits; here are the ones related to the `unbundle_imap_pspel
On 11/08/2024 17:55, Christoph M. Becker wrote:
On a general note, the whole administrative part of the RFC process
feels like we're stuck in the 20th century. For instance, to start the
vote, you are supposed to:
* update the RFC page to "voting" status
* add the doodle voting macro
* add the
> On 11 Aug 2024, at 13:59, Christoph M. Becker wrote:
>
> On a general note, the whole administrative part of the RFC process
> feels like we're stuck in the 20th century. For instance, to start the
> vote, you are supposed to:
>
> * update the RFC page to "voting" status
> * add the doodle
> I've fixed up the first two, but I haven't yet found the PRs regarding
> the extension unbundling [snip]
>
I'm watching the php-src repo for some writing stuff and noted down the
commits; here are the ones related to the `unbundle_imap_pspell_oci8` RFC.
Hope it helps :)
- Remove `pdo_oci` and
On Sun, Aug 11, 2024, 8:32 PM Gina P. Banyard wrote:
> On Sunday, 11 August 2024 at 15:26, Pierre Joye
> wrote:
>
>
>
> On Sun, Aug 11, 2024, 6:53 PM Gina P. Banyard wrote:
>
>> On Saturday, 10 August 2024 at 15:13, Christoph M. Becker <
>> cmbecke...@gmx.de> wrote:
>>
>> I think moving the PDO
2024年8月12日(月) 1:42 Anton Smirnov :
>
> Hi Nick,
>
> As a developer who often deals with binary data (like bencode, ipv6
> addresses and my own hacks for multibyte arithmetic) I would prefer that
> functions and syntaxes that allow me to work with bytes keep working
> with bytes, not characters or c
On Sun, Aug 11, 2024, at 10:50 AM, Nick Lockheart wrote:
> HTML 5 was adopted in 2014, over ten years ago. HTML 5 only supports
> the UTF-8 multi-byte character encoding.
>
> It seems like there's still a lot of string functions that assume that
> a character is a single byte, and these may actuall
On Sun, Aug 11, 2024 at 9:23 AM Nick Lockheart wrote:
> On Sat, 2024-08-10 at 23:37 +0100, Bilge wrote:
> > On 10/08/2024 23:32, Nick Lockheart wrote:
> > > > Voting has now concluded for static class. The first vote cast
> > > > was
> > > > for, and of the first four votes cast, three were for a
On 11.08.2024 at 08:05, Juliette Reinders Folmer wrote:
> I'm currently going through the RFC wiki page and I'm seeing various
> (PHP 8.4) RFCs which haven't been properly updated after the vote.
>
> I've not gone through all of the RFCs, but these are definitely some
> which I'd like to flag for
On Sat, Aug 10, 2024 at 7:16 AM Christoph M. Becker
wrote:
> Hi all,
>
> a week ago Denis Simonov submitted a PR[1] regarding formatting of the
> new time zone types of Firebird 4.0 (which appears sensible per se).
> This requires to access new Firebird APIs which are written in C++ (the
> old In
Hi Nick,
As a developer who often deals with binary data (like bencode, ipv6
addresses and my own hacks for multibyte arithmetic) I would prefer that
functions and syntaxes that allow me to work with bytes keep working
with bytes, not characters or code points. So the closest solution would
b
To mbstring.func_overload
On 8/11/24 19:22, Bilge wrote:
Are we going back to PHP 6?
Are we going back to PHP 6?
Hi
On 8/11/24 17:50, Nick Lockheart wrote:
It seems like there's still a lot of string functions that assume that
a character is a single byte, and these may actually work as expected
when dealing with Latin characters, but may fail unexpectedly if a
sequence is more than one byte.
PHP's strin
HTML 5 was adopted in 2014, over ten years ago. HTML 5 only supports
the UTF-8 multi-byte character encoding.
It seems like there's still a lot of string functions that assume that
a character is a single byte, and these may actually work as expected
when dealing with Latin characters, but may f
On Sunday, 11 August 2024 at 17:27, Giovanni Giacobbi
wrote:
> On Sun, 11 Aug 2024 at 16:12, Ilija Tovilo wrote:
>
>> Hi Christoph
>>
>> On Sat, Aug 10, 2024 at 2:19 PM Christoph M. Becker
>> wrote:
>>>
>>> On 01.08.2024 at 23:57, Ilija Tovilo wrote:
>>>
>>> So skimming the whole discussion[1
On Sun, 11 Aug 2024 at 16:12, Ilija Tovilo wrote:
> Hi Christoph
>
> On Sat, Aug 10, 2024 at 2:19 PM Christoph M. Becker
> wrote:
> >
> > On 01.08.2024 at 23:57, Ilija Tovilo wrote:
> >
> > So skimming the whole discussion[1] it seems that most are generally
> > fine with bumping the requirement
On Sat, 2024-08-10 at 23:37 +0100, Bilge wrote:
> On 10/08/2024 23:32, Nick Lockheart wrote:
> > > Voting has now concluded for static class. The first vote cast
> > > was
> > > for, and of the first four votes cast, three were for and one was
> > > against. As the votes continued to roll in, howev
> Giovanni's remark that this would impact many people was challenged by
> Jakub [1] which didn't get a response. I believe it's safe to assume
> that this isn't the case.
I somehow forgot to link this reference, sorry about that.
[1] https://externals.io/message/124706#124717
Hi Christoph
On Sat, Aug 10, 2024 at 2:19 PM Christoph M. Becker wrote:
>
> On 01.08.2024 at 23:57, Ilija Tovilo wrote:
>
> So skimming the whole discussion[1] it seems that most are generally
> fine with bumping the requirements to C11, except for Giovanni Giacobbi
> (whose draft PR[2] had no fu
On Sunday, 11 August 2024 at 15:26, Pierre Joye wrote:
> On Sun, Aug 11, 2024, 6:53 PM Gina P. Banyard wrote:
>
>> On Saturday, 10 August 2024 at 15:13, Christoph M. Becker
>> wrote:
>>
>> I think moving the PDO driver to use C++ is a more sensible choice.
>
> what would be the advantages? giv
On Sun, Aug 11, 2024, 6:53 PM Gina P. Banyard wrote:
> On Saturday, 10 August 2024 at 15:13, Christoph M. Becker <
> cmbecke...@gmx.de> wrote:
>
> I think moving the PDO driver to use C++ is a more sensible choice.
>
what would be the advantages? given the OO part at the C level is perfectly
fi
On Saturday, 10 August 2024 at 15:13, Christoph M. Becker
wrote:
> Hi all,
>
> a week ago Denis Simonov submitted a PR[1] regarding formatting of the
> new time zone types of Firebird 4.0 (which appears sensible per se).
> This requires to access new Firebird APIs which are written in C++ (the
On Sat, Aug 10, 2024 at 4:15 PM Christoph M. Becker
wrote:
> So what do you think? Should we use C++ to access the new APIs, or
> stick with C (and include the required declarations in PDO_Firebird)?
>
There's at least one another extension that requires C++ - intl. And it's a
much more used on
>
> Hi all,
>
> We have just opened the vote for the Lazy Objects RFC:
> https://wiki.php.net/rfc/lazy-objects
>
> The vote will close on August 11th à 00:00.
>
> Please check the discussion thread if you didn't follow it already:
> https://externals.io/message/123503
>
> Cheers,
> Nicolas and Ar
38 matches
Mail list logo
