Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tuesday, 25 June 2024 at 15:36, Gina P. Banyard wrote: > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 7/16/24 13:04, Christoph M. Becker wrote: See also a respective GH issue regarding deprecation messages: ; it probably makes sense to include an URL in the deprecation message, or maybe some code which users can use to look up more thorough info

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi Tim! On 15.07.2024 at 23:50, Tim Düsterhus wrote: >> That doesn't mean that I'm against the uniqid() deprecation, especially >> if the deprecation message is clear on what to use instead. > > I will make sure to write useful migration docs, helping users making an > educated choice for an alte

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tue, Jul 16, 2024, at 01:08, Rob Landers wrote: > > > On Mon, Jul 15, 2024, at 23:29, Tim Düsterhus wrote: >> Hi >> >> On 7/15/24 16:12, Rob Landers wrote: >> > This always gets me. "safer" doesn't have a consistent meaning. For >> >> Yes it does. SHA-256 is safer than MD5. And on modern C

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Mon, Jul 15, 2024, at 23:29, Tim Düsterhus wrote: > Hi > > On 7/15/24 16:12, Rob Landers wrote: > > This always gets me. "safer" doesn't have a consistent meaning. For > > Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni > extensions, it's also faster. The following is

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Mon, Jul 15, 2024 at 4:31 PM Tim Düsterhus wrote: > > Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni > extensions, it's also faster. The following is on a Intel i7-1365U: > > > $ openssl speed md5 sha1 sha256 sha512 > > *snip* > > version: 3.0.10 > > built on: Wed Feb 21

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 7/15/24 15:56, Christoph M. Becker wrote: I do not, however, agree with the reasoning that a function (like uniqid()) is often used in a unsafe way (i.e. for purposes it has not been designed), and therefore should be deprecated/removed. There are likely a couple of developers who are eas

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 7/15/24 16:12, Rob Landers wrote: This always gets me. "safer" doesn't have a consistent meaning. For Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni extensions, it's also faster. The following is on a Intel i7-1365U: $ openssl speed md5 sha1 sha256 sha512 *sni

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 7/8/24 07:25, Andreas Heigl wrote: I don't mind putting the work in when there is a good justification, but I don't see one for this deprecation. The only one I can see is cleaning up the codebase and removing duplicate methods. But the RFC definitely states that it is to "encourage user

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Mon, Jul 15, 2024, at 13:20, Gina P. Banyard wrote: > On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer > wrote: > > On 2-7-2024 20:05, Gina P. Banyard wrote: > >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer > >> wrote: > >> > >>> * While a number of proposals includ

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 08.07.2024 at 05:04, Juliette Reinders Folmer wrote: > On 2-7-2024 20:05, Gina P. Banyard wrote: > >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer >> wrote: >> >>> Other than that, I join the previously voiced objections to the >>> deprecation of `uniqid()`, `md5()`, `sha1()`, `m

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer wrote: > On 2-7-2024 20:05, Gina P. Banyard wrote: >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer >> wrote: >> >>> * While a number of proposals include an impact analysis (thank you!), a >>> significant number of the pro

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jul 8, 2024, at 12:03 PM, Alexandru Pătrănescu wrote: > Managed to simplify it like this and I find it reasonable enough: > function strtok2(string $string, ?string $token = null): string|false { > static $tokenGenerator = null; > if ($token) { > $tokenGenerator = (function(st

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Le 6 juil. 2024 à 03:22, Mike Schinkel a écrit :On Jul 5, 2024, at 1:11 PM, Claude Pache wrote:Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit :https://wiki.php.net/rfc/deprecations_php_8_4* About strtok(): An exact replacement of `strtok()` that is re

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Mon, Jul 8, 2024 at 6:43 PM Alexandru Pătrănescu wrote: > > I'm hoping this can be simplified further, but to get to the point, I also > think we should have a userland replacement suggestion in the RFC. > > Managed to simplify it like this and I find it reasonable enough: function strtok2(st

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Sat, Jul 6, 2024 at 4:25 AM Mike Schinkel wrote: > > On Jul 5, 2024, at 1:11 PM, Claude Pache wrote: > > Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit : > https://wiki.php.net/rfc/deprecations_php_8_4 > > > * About strtok(): An exact replacement of `strtok()` that is reasonably > performa

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 08/07/2024 05:04, Juliette Reinders Folmer wrote: > I'd suggest for an impact analysis/expected impact statement to be added to > the following deprecation proposals: > (...) > > And to a lesser degree for: > (...) > * Deprecate passing incorrect data types for options to ext/hash functions S

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 08/07/2024 01:12, Gina P. Banyard wrote: > On Friday, 5 July 2024 at 18:11, Claude Pache wrote: >> * I don’t see the point of deprecating DOMImplementation::getFeature() >> instead of just removing it? “DOMImplementation::getFeature() is deprecated, >> throw manually an Error exception instea

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hey all Am 08.07.24 um 07:05 schrieb Juliette Reinders Folmer: On 8-7-2024 6:57, Andreas Heigl wrote: Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The  suggested `hash()` replacements for the md5/s

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 8-7-2024 6:57, Andreas Heigl wrote: Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The suggested `hash()` replacements for the md5/sha1* functions have the exact same functionality, which the RFC

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The  suggested `hash()` replacements for the md5/sha1* functions have the exact same functionality, which the RFC considers "incorrect use", so what are w

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 2-7-2024 20:05, Gina P. Banyard wrote: On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer wrote: On 25-6-2024 16:36, Gina P. Banyard wrote: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc/deprecat

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Friday, 5 July 2024 at 18:11, Claude Pache wrote: > * For each deprecation, it would be nice to provide explicitly the text of > the deprecation notice so that we can guarantee that it will be helpful for > users, see https://github.com/php/php-src/issues/14320 Considering that until recent

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jul 5, 2024, at 1:11 PM, Claude Pache wrote: >> Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit : >> https://wiki.php.net/rfc/deprecations_php_8_4 > > > * About strtok(): An exact replacement of `strtok()` that is reasonably > performant may be constructed with a sequence of strspn(...)

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit : > > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > Hi, * For each deprecation, it would be nice to provide explicitly

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tuesday, 25 June 2024 at 15:36, Gina P. Banyard wrote: > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer wrote: > On 25-6-2024 16:36, Gina P. Banyard wrote: > >> Hello internals, >> >> It is this time of year again where we proposed a list of deprecations to >> add in PHP 8.4: >> https://wiki.php.net/rfc/deprecations_php_8_4 >> As a remind

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tuesday, 2 July 2024 at 07:49, Marc Bennewitz wrote: > Hi Gina, > > On 25.06.24 16:36, Gina P. Banyard wrote: > >> Hello internals, >> >> It is this time of year again where we proposed a list of deprecations to >> add in PHP 8.4: >> https://wiki.php.net/rfc/deprecations_php_8_4 >> As a remin

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 2024-07-02 21:52, Juliette Reinders Folmer wrote: Other than that, I join the previously voiced objections to the deprecation of `uniqid()`, `md5()`, `sha1()`, `md5_file()`, `sha1_file()`. While I acknowledge that these functions _can_ be used inappropriately for security-sensitive code, whic

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 25-6-2024 16:36, Gina P. Banyard wrote: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc/deprecations_php_8_4 As a reminder, this list has been compiled over the course of the past year by various different

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi Gina, On 25.06.24 16:36, Gina P. Banyard wrote: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc/deprecations_php_8_4 As a reminder, this list has been compiled over the course of the past year by various

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/29/24 23:23, mickmackusa wrote: If one can easily use a function incorrectly in a way that is not *immediately* apparent, then I consider the function to be badly designed. Does that philosophy also cover preg_quote()? I've lost count of the Yes, it does. Would it be reasonable

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Saturday, 29 June 2024 at 22:23, mickmackusa wrote: >> If one can easily use a function incorrectly in a way that is not >> *immediately* apparent, then I consider the function to be badly >> designed. > > Does that philosophy also cover preg_quote()? I've lost count of the number > of times

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> > If one can easily use a function incorrectly in a way that is not > *immediately* apparent, then I consider the function to be badly > designed. > Does that philosophy also cover preg_quote()? I've lost count of the number of times that I've seen it used in Stack Overflow answers without a se

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

I have added one more deprecation Deprecate the second parameter to mysqli_store_result().

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jun 27, 2024, at 11:26 AM, Tim Düsterhus wrote: > > Hi > > On 6/27/24 19:09, Chuck Adams wrote: >> Personally I say let strtok be and just admit in the documentation that it’s >> weird because C. > > strtok() is not weird because C. It does not rely on the libc strtok() > function and

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/27/24 19:09, Chuck Adams wrote: Personally I say let strtok be and just admit in the documentation that it’s weird because C. strtok() is not weird because C. It does not rely on the libc strtok() function and did not since at least 1999 (and likely never did): https://github.com/ph

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/27/24 09:44, Markus Podar wrote: 👎 on deprecating it; if a gotcha with it is not clear (e.g. using it in different scopes, as this was brought up), I see this rather as a "documentation problem". If one can easily use a function incorrectly in a way that is not *immediately* apparent,

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jun 27, 2024, at 2:22 AM, Stephen Reay wrote: > > I do appreciate that strtok has a kind of bizarre signature/use pattern and > potential for confusion due to how subsequent calls work, but to me that > sounds like a better result for uses that need the repeated call > functionality, would

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/26/24 14:14, Gina P. Banyard wrote: Regarding explode($delimiter, $str)[0] — unless it is to be special-cased during compilation —it is a really inefficient way to find the substring up to the first character, especially for large strings and/or when in a tight loop where the explode

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Thursday, 27 June 2024 at 11:22, Kamil Tekiela wrote: > > Yes, that is a better description. I have updated this section of the RFC. Best regards, Gina P. Banyard

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Thu, 27 Jun 2024 at 05:57, Gina P. Banyard wrote: > > On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela > wrote: > > > I think the "Deprecate passing E_USER_ERROR to trigger_error()" should > > be better explained. Why is using this constant a problem? There is a > > link to another RFC, but

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On 27 Jun 2024, at 12:31, Mike Schinkel wrote: > >> On Jun 26, 2024, at 8:14 AM, Gina P. Banyard > > wrote: >> >> >> On Wednesday, 26 June 2024 at 06:18, Mike Schinkel > > wrote: >>> https://3v4l.org/RDYFs#v8.3.8 >>> >>> Note those seve

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi, On 26.06.24 07:18, Mike Schinkel wrote: On Jun 25, 2024, at 4:51 PM, Gina P. Banyard > wrote: On Tuesday, 25 June 2024 at 19:06, Mike Schinkel > wrote: strtok() = strtok() is found 35k times in GitHub: https://github.com/sear

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jun 26, 2024, at 8:14 AM, Gina P. Banyard wrote: > > > On Wednesday, 26 June 2024 at 06:18, Mike Schinkel > wrote: >> https://3v4l.org/RDYFs#v8.3.8 >> >> Note those seven use-cases are found in around the first 25 results when >> searching GitHub for "str

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tuesday, 25 June 2024 at 23:29, Bruce Weirdan wrote: > Is there a reason to keep crc32? Good question, I had a chat with Tim as I thought it was similar to the md5()/sha1() functions. Moreover, the crc32() function returns an int, whereas the equivalent of the hash extension returns a strin

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela wrote: > I think the "Deprecate passing E_USER_ERROR to trigger_error()" should > be better explained. Why is using this constant a problem? There is a > link to another RFC, but I can't see an explanation as to why > E_USER_ERROR suffers the sam

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Wednesday, 26 June 2024 at 20:19, Morgan wrote: > I do not believe it is appropriate to deprecate strtok() without a proper > replacement. > > While I agree that its signature is undesirable, the suggested replacement > functions or “just write a parser” are not very pleasant solutions to fi

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

I do not believe it is appropriate to deprecate strtok() without a proper replacement. While I agree that its signature is undesirable, the suggested replacement functions or “just write a parser” are not very pleasant solutions to fill the void it would leave. The stateful functionality it exhib

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

I think the "Deprecate passing E_USER_ERROR to trigger_error()" should be better explained. Why is using this constant a problem? There is a link to another RFC, but I can't see an explanation as to why E_USER_ERROR suffers the same problem as fatal errors do. From an average Joe's perspective, it

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Wednesday, 26 June 2024 at 06:39, Dusk wrote: > On Jun 25, 2024, at 22:18, Mike Schinkel m...@newclarity.net wrote: > > > This leads me to think `strtok()` should not be deprecated given how > > inefficient string handling in PHP can otherwise be, at least not without a > > much more effici

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Wednesday, 26 June 2024 at 06:18, Mike Schinkel wrote: >> https://3v4l.org/RDYFs#v8.3.8 > > Note those seven use-cases are found in around the first 25 results when > searching GitHub for "strtok(". I could probably find more if I kept looking: > >> https://github.com/search?q=strtok%28+langu

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jun 26, 2024, at 1:39 AM, Dusk wrote: > > On Jun 25, 2024, at 22:18, Mike Schinkel wrote: >> This leads me to think `strtok()` should not be deprecated given how >> inefficient string handling in PHP can otherwise be, at least not without a >> much more efficient object for string parsing

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Jun 25, 2024, at 22:18, Mike Schinkel wrote: > This leads me to think `strtok()` should not be deprecated given how > inefficient string handling in PHP can otherwise be, at least not without a > much more efficient object for string parsing. What would be really useful as a replacement for

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jun 25, 2024, at 4:51 PM, Gina P. Banyard wrote: > > > On Tuesday, 25 June 2024 at 19:06, Mike Schinkel wrote: >> >> strtok() >> = >> strtok() is found 35k times in GitHub: >> >> https://github.com/search?q=strtok%28+language%3APHP+&type=code >>

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Is there a reason to keep crc32? -- Best regards, Bruce Weirdan mailto: weir...@gmail.com

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tuesday, 25 June 2024 at 19:06, Mike Schinkel wrote: > strtok() > = > strtok() is found 35k times in GitHub: > >> https://github.com/search?q=md5%28+language%3APHP+&type=code > > It is a commonly used as a "left part of string up to a character" in > addition to its intended use for token

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/25/24 17:49, Derick Rethans wrote: These functions are indeed often used. The documentation for uniqid has some nice big warnings too. It can be used in situations, where it is OK. Yes, the RFC acknowledges that. Replacing the algorithm underneath uniqid can (and perhaps should) be l

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/25/24 17:39, Rob Landers wrote: My only issue is md5, sha1, etc. There are many uses for them besides secure contexts. Sha1 is used by git, md5 fits snuggly in many data structures (uuidv5, for example, though some implementations also use the first 128 bits of a sha1). I believe yo

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> On Jun 25, 2024, at 10:36 AM, Gina P. Banyard > wrote: > > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 >

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/25/24 18:03, Rowan Tommins [IMSoP] wrote: Then again, if you _actually_ want it to be unique, rather than random, those aren't the right replacements anyway. They are for all intents and purposes if the generated string is long enough. By the pigeonhole principle you can't guarantee u

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hi On 6/25/24 17:55, Marco Pivetta wrote: Update: Tim gave me a decent alternative that I can live with. `uniqid()` becomes `bin2hex(random_bytes(16))`. For context: Marco also pinged me on Roave Discord and I sent a quick reply from my phone. I've now added the `bin2hex(random_bytes(16))`

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 25/06/2024 16:27, Marco Pivetta wrote:  * `uniqid()`, in my case (XKCD 1172) is largely used for quickly generating a semi-random string for test purposes: a suitable replacement PRNG implementation would be welcome. Even refactoring with tools like Rector will lead to quite messy code, or

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tue, 25 Jun 2024 at 17:27, Marco Pivetta wrote: > * `uniqid()`, in my case (XKCD 1172) is largely used for quickly > generating a semi-random string for test purposes: a suitable replacement > PRNG implementation would be welcome. Even refactoring with tools like > Rector will lead to quite m

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Please, no top posting. On Tue, 25 Jun 2024, Marco Pivetta wrote: > I agree with most of these deprecations, except: > > * `uniqid()`, in my case (XKCD 1172) is largely used for quickly > generating a semi-random string for test purposes: a suitable replacement > PRNG implementation would be we

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Tue, Jun 25, 2024, at 16:36, Gina P. Banyard wrote: > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the past

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Hey Gina, Tim, I agree with most of these deprecations, except: * `uniqid()`, in my case (XKCD 1172) is largely used for quickly generating a semi-random string for test purposes: a suitable replacement PRNG implementation would be welcome. Even refactoring with tools like Rector will lead to qu