2022年2月18日(金) 19:46 Tim Düsterhus :
> Hi
>
> On 2/18/22 07:31, Go Kudo wrote:
> > I have been looking into output buffering, but don't know the right way
> to
> > do it. The buffering works fine if all RNG generation widths are static,
> > but if they are dynamic so complicated.
>
> I believe the
On Sun, 20 Feb 2022 at 23:12, Rowan Tommins wrote:
> I don't have hard facts to back it up, but my impression is that
> ext/mbstring is quite commonly installed, and required by apps and
> libraries. Unlike the other two, it has no system dependencies, because
> the implementation is entirely in
On 20/02/2022 21:24, Craig Francis wrote:
Only query I have is about the availability of different functions...
not sure why, but the documentation says these are provided by the
"xml" extension, even though it looks like they are in
`./standard/string.c` (your pull request seems to correct t
On Sun, 20 Feb 2022 at 18:55, Rowan Tommins wrote:
> I would like to open discussion on an RFC to deprecate and later remove
> the functions utf8_encode() and utf8_decode()
>
> https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
>
Thanks Rowan.
Whenever I see these functions being used
On Sat, 1 Jan 2022 at 23:17, Craig Francis wrote:
> Draft RFC:
> https://wiki.php.net/rfc/allow_null
>
I've been over-complicating this... why should NULL be treated so
differently?
It just struck me, this whole thing is about type coercion when not using
`strict_types=1`; and the 8.1 change
Good $daypart everybody,
I would like to open discussion on an RFC to deprecate and later remove
the functions utf8_encode() and utf8_decode()
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
This is not a straight-forward decision, because these functions are not
actually broken,
Hello internals,
As a follow up from the "Allow null as a stand-alone type" where the main
talking point was to also allow false to be used as a stand-alone type, a
new slightly modified RFC is now proposed:
https://wiki.php.net/rfc/null-false-standalone-types
The implementation has been updated
I think it's a great idea to deprecate crypt(). I wouldn't want anyone to
use it in a new code. For legacy applications, we are giving them enough
time to upgrade their password storing policy. Also, it's not like we are
removing support for hashing in general from PHP, we are just deprecating a
fu
On Sun, 20 Feb 2022, 14:17 Tim Düsterhus, wrote:
> Hi Steve,
>
> On 2/20/22 12:44, st...@tobtu.com wrote:
>
>
> > If that's the case, you may not know that password_verify() can verify
> all password hashes created by crypt(). The whole point of deprecating and
> finally removing crypt() is that
Hi Steve,
On 2/20/22 12:44, st...@tobtu.com wrote:
Also ~99% of implementations of crypt() that use sha256crypt and/or sha512crypt
password hashing algorithms are vulnerable to a long password DoS attack. Since
they don't know they need to limit the password length because the runtime is
O(pw
> On 02/20/2022 1:10 AM Stanislav Malyshev wrote:
>
>
> Hi!
>
> On 2/19/22 6:03 PM, st...@tobtu.com wrote:
> > crypt() should be deprecate because it can be used to create bad password
> > hashes:
>
> I don't think it's a good reason for deprecating functions. A lot of
> functions, if used
11 matches
Mail list logo
