date:20220217

Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion

2022-02-17 Thread Robert Landers

Hi Mark,

Just out of curiosity, why is the 3rd case being included here? Is it just
because it's currently a warning? The current behavior is well documented
and known since ... forever? When I first taught PHP in 2011, I was told
post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1` and if
I wanted different behavior I needed to write it out. Maybe that original
behavior was unintentional, but this seems like a pretty fundamental change
to something that has been that way since the beginning just to "make it
work like other languages"?

Robert Landers
Software Engineer
Utrecht NL

On Fri, Feb 18, 2022 at 12:28 AM Mark Randall  wrote:

> Internals,
>
> Following on from my previous thread, I think we are now in a position
> where we can begin formal discussions on an RFC to promote undefined
> variables to Error exceptions in PHP 9.0.
>
> I present:
>
> https://wiki.php.net/rfc/undefined_variable_error_promotion
>
> I still intend to bring other error promotions forward, potentially in
> collaboration with other developers, but as this is the biggest change,
> and the most likely to attract a large number of comments, I thought it
> deserving of a standalone RFC.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

2022-02-17 Thread Go Kudo

2022年2月17日(木) 19:25 Tim Düsterhus :

> Hi
>
> On 2/17/22 08:37, Go Kudo wrote:
> > The following points have been fixed:
> >
> > - `nextByteSize(): int` has been removed from Random\Engine
> > - If the width of the RNG is statically defined, it will now be used
> > preferentially
> > - Added Xoshiro256StarStar
> > - Fixed an endianness issue
> >
> > And updated RFC
> >
> > https://wiki.php.net/rfc/rng_extension
> >
> > [...]
> > This seems to have solved the whole problem. How about it?
>
> Awesome, this is feeling much much better now. As you might've seen I've
> made some comments on GitHub regarding implementation bugs.
>
> I have two more conceptional questions:
>
> ---
>
> 1)
>
> However I believe you did not answer my question regarding the following
> and that's something that should be clear in the RFC and documentation:
>
>  
>  use Random\Engine\Xoshiro256StarStar;
>  use Random\Randomizer;
>
>  $g1 = new Xoshiro256StarStar(1);
>  $g2 = clone $g1;
>  $r1 = new Randomizer($g1);
>  $r2 = new Randomizer($g2);
>
>  var_dump(\bin2hex($r1->getBytes(8))); // string(16) "c510c70f6daff2b3"
>  var_dump(\bin2hex($r2->getBytes(4) . $r2->getBytes(4))); //
> string(16) "c510c70fea4c3647"
>
>
> In this example I get 8 bytes from the randomizer. One time by getting
> all 8 bytes at once, the second time by getting 4 bytes and then another
> 4 bytes.
>
> I think that both lines should result in the same output, because in
> both cases I am getting 8 bytes, without any other operations that might
> affect the engine state in between. As a user I should not be required
> to know how the Randomizer works internally (by always getting 8 bytes
> from the engine and throwing away unused bytes).
>
> If you disagree and think this is the correct behavior then this should
> be documented accordingly in the RFC. If you agree, then this should be
> fixed and a testcase be added.
>
> ---
>
> 2)
>
> This ties into (1): Currently any additional bytes returned by the
> engine are silently ignored. Either the bytes should be processed in
> full, or an error emitted if the returned bytestring is too long.
>
> Consider the attached test case with a Sha1-based RNG. If I grab 20
> bytes (the length of a SHA-1 hash) from the Randomizer then the
> 'generate()' function will be called 3 times, despite it returning
> sufficient bytes on the first attempt. If I want to make sure that no
> bytes are wasted, then I need to implement a pretty complex construction
> (Sha1_2) to always return exactly 8 bytes.
>
> Best regards
> Tim Düsterhus


Hi

Hello.

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.

It is possible to solve this problem by allowing generate() itself to
specify the size it wants, but this would significantly slow down
performance.

I've looked at the sample code, but do you really need support for
Randomizer? Engine::generate() can output dynamic binaries up to 64 bits.
You can use Engine directly, instead of Randomizer::getBytes().

What exactly is the situation where buffering by Randomizer is needed?

Also worried that buffering will cut off random numbers at arbitrary sizes.
It may cause bias in the generated results.

If you don't want to waste the generated values, users can still implement
their own buffering structures into Random\Engine following.

```php
gen = $this->stream($seed);
$this->buffer = '';
}

private function stream($state)
{
while (true) {
$state = \sha1($state, true);
for ($i = 0; $i < \strlen($state); $i++) {
yield $state[$i];
}
}
}

public function generate(): string
{
echo __METHOD__, PHP_EOL;

$result = "";
for ($i = 0; $i < 8; $i++) {
$result .= $this->gen->current();
$this->gen->next();
}

return $result;
}

public function getBytes(int $length): string
{
$result = '';

while (\strlen($result) < $length) {
if ($this->buffer === '') {
$this->buffer = $this->generate();
}
$required = $length - \strlen($result);
$temp = \substr($this->buffer, 0, $required);
$this->buffer = \substr($this->buffer, $required);
$result .= $temp;
}

return $result;
}
}
```

Buffering mechanism that was implemented in a limited way has been reverted
recently.

Best Regards
Go Kudo

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

2022-02-17 Thread Go Kudo

2022年2月17日(木) 19:25 Tim Düsterhus :

> Hi
>
> On 2/17/22 08:37, Go Kudo wrote:
> > The following points have been fixed:
> >
> > - `nextByteSize(): int` has been removed from Random\Engine
> > - If the width of the RNG is statically defined, it will now be used
> > preferentially
> > - Added Xoshiro256StarStar
> > - Fixed an endianness issue
> >
> > And updated RFC
> >
> > https://wiki.php.net/rfc/rng_extension
> >
> > [...]
> > This seems to have solved the whole problem. How about it?
>
> Awesome, this is feeling much much better now. As you might've seen I've
> made some comments on GitHub regarding implementation bugs.
>
> I have two more conceptional questions:
>
> ---
>
> 1)
>
> However I believe you did not answer my question regarding the following
> and that's something that should be clear in the RFC and documentation:
>
>  
>  use Random\Engine\Xoshiro256StarStar;
>  use Random\Randomizer;
>
>  $g1 = new Xoshiro256StarStar(1);
>  $g2 = clone $g1;
>  $r1 = new Randomizer($g1);
>  $r2 = new Randomizer($g2);
>
>  var_dump(\bin2hex($r1->getBytes(8))); // string(16) "c510c70f6daff2b3"
>  var_dump(\bin2hex($r2->getBytes(4) . $r2->getBytes(4))); //
> string(16) "c510c70fea4c3647"
>
>
> In this example I get 8 bytes from the randomizer. One time by getting
> all 8 bytes at once, the second time by getting 4 bytes and then another
> 4 bytes.
>
> I think that both lines should result in the same output, because in
> both cases I am getting 8 bytes, without any other operations that might
> affect the engine state in between. As a user I should not be required
> to know how the Randomizer works internally (by always getting 8 bytes
> from the engine and throwing away unused bytes).
>
> If you disagree and think this is the correct behavior then this should
> be documented accordingly in the RFC. If you agree, then this should be
> fixed and a testcase be added.
>
> ---
>
> 2)
>
> This ties into (1): Currently any additional bytes returned by the
> engine are silently ignored. Either the bytes should be processed in
> full, or an error emitted if the returned bytestring is too long.
>
> Consider the attached test case with a Sha1-based RNG. If I grab 20
> bytes (the length of a SHA-1 hash) from the Randomizer then the
> 'generate()' function will be called 3 times, despite it returning
> sufficient bytes on the first attempt. If I want to make sure that no
> bytes are wasted, then I need to implement a pretty complex construction
> (Sha1_2) to always return exactly 8 bytes.
>
> Best regards
> Tim Düsterhus


Hi Tim
Thanks for your continued help!

As for your question, buffering the output can lead to counter-intuitive
behavior in code like the following.

```php
getBytes(2);

// Generate a new 64 bits (to waste)
$engine->generate();

// Retrieve 64 bits (first 48 bits from buffer, but last 16 bits newly
generated)
// numerical continuity will be lost.
$str2 = $randomizer->getBytes(8);
```

However, the Engine will probably not be used by itself very often. I think
buffering should be implemented, but I'd like to solicit opinions on this
in the ML.

I'll implement value buffering first.

Regards
Go Kudo

[PHP-DEV] PHP 8.1.3 Released

2022-02-17 Thread Patrick ALLAERT

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The PHP development team announces the immediate availability of PHP
8.1.3. This is a security release.

All PHP 8.1 users are encouraged to upgrade to this version.

For source downloads of PHP 8.1.3 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at
https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8

Many thanks to all the contributors and supporters!
Ben Ramsey, Patrick Allaert & Joe Watkins

Release Manifest here and below:
https://gist.github.com/patrickallaert/ecac28db4cd24723050d50ca30c563a0

php-8.1.3.tar.bz2
SHA256 hash:
354c4e2c506046eca812d1fc2526884a2f54b5e3d20ef0ede919a69eb232d0be
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmIMTZ4ACgkQGZ+d/vb/
uv3YvhAAv7fJAE/ZjYL9sNuF8q2UZz1P3Sxd2PX1FHeadLnX1RWkQFv+pCdD/+rR
b+HrD6mnzJYjzT/9EGL3+rLP4byWOGWX46jVWvdyWWluGRz4sP9kUjvVYmMRIRtF
4joY3HqxLaKqlKPo+9gFYJo2NZ5H4QRAB0Eg/1RDn5VS/NVXcYVUUoE/E5u0zv8u
CsPR14mD59jkON/qYzSswoK1V4QwKNr3sW5+feziJM1mBl9d7lcc0E5wqNQES0+V
qZoOZE/KsfThdbDnEd3m27Ar5UdKj/yptrcDq8YrCbumbdt3KRDV+wVhWzV1KFO5
RynOKmxcId17RfatB3/d8SheyZivyQiHtI8utwtEGthyPSFGQE2ml42ilAOMLgdi
y/V6oxYHaNhmEhyXGiCOGZY3PyxyyDzMsNgMD/1XjnzPH3Gr8Ar/bS8PVFyfJvY4
aFf55Tm8piQegkcMz34d2MpdRa8Pu0HXFscl/zxc6xoPogw/rkEsBA8zR7V/YC+T
mzKErjM66Gpf2Cl5NoeOVo61y8dpyWR60ysgQIkhUjheJA3E0d4LtsQ3LLdOAL8l
UlJeBOvWu16MloHqNJ4+AjVaBu+HMIWSqWjMuZGcQ/N+4DS2hJ97s2yPru15tCw5
aK0B+TUrXtswjyPSQ6Ytt2ybBz848z4C17EFtGHAs/+/mPmiX5I=
=1Mik
- -END PGP SIGNATURE-

php-8.1.3.tar.gz
SHA256 hash:
92d74f5a4af7de90cef6cda65bd0c341dc9a1027b32f70e7b8861f6f68a38bb2
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmIMTZ4ACgkQGZ+d/vb/
uv2rYhAAtQkhJqSuFBhanVGjvS0kxhXpVwJBxi0wRiuBwCvK8zBrlTUDp4MBzNlC
TieTkokk1TYnUiEM0WpOUrmOVC+kJTZHB1waf+6D9Rl93CtEnyHI/Joy/cXCl1QX
qS0UZztFAaZNaUfyXGA2+vvlpu228p5eg7DW72rzeScYTwPXjWzKWaClTK+kZppL
PEF484Y6FtTEy9uHFPc4AIA/nUq336Uj3ZPl5Aa7yCp9WwRl925obWXGXJeZ4w25
nkQvi8BGz7ZLmiauLeW24CAd+KN0+8z5UtU08uTxzk/LY2X5qGhVKFOxoiCpgQnf
s13x9dpQiLbx4ZC9bd8bVkbqMAjsNDar3AjpVwjlTf4alQd6rzABFeDstqJJZp3P
GHM6MiYxt8rGic2rW+zwlwfWyp3KY4qynbqmIzbKc7TUSkTw0+r6SLLnnAUInHsp
9LNMGXXGtIK15O90N7uuMIon5EWYpB663R58u1h6TYk81cf/1h7p+rJTqlRMpgbY
xi/fNMVvAxzaZLZbdXoDnHbr6AcM17YglohJNkPER4eczI5db5eKaFk+WiZvzuNn
ms7PwQzpgnM7QfvFlxUH/dwkhEBUW/nbMwxUXCWAsRUP6Xy3C0JKThfZSWZ7vvIq
Z7IEOV8nTbS3SiEKY8WD3Z1TGk63FSBfKNy1pS1UdGQDunukI9g=
=Xnlz
- -END PGP SIGNATURE-

php-8.1.3.tar.xz
SHA256 hash:
5d65a11071b47669c17452fb336c290b67c101efb745c1dbe7525b5caf546ec6
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmIMTZ4ACgkQGZ+d/vb/
uv3qwA/+IqaKf1tx9WIg3n9Jw9UPBz6UMWU4wYX4fCm1u118vyLJEDvPOn6fhJTV
3GiJf+qJ7/vGBsCtbIIc7SbunDUqsYhgfNPOzn0X4034bY7lSFHoC4DZX/+4XqWO
NfCa0+5hfclwB6EIMyUdaiAHPdgT56TXEIJ2/u4ku8va7c3Ykk9u+YYcYE51yPlA
5wxpy9Y4avukX7pJ+1ekFvRR66Bmt4lCNCg91NIQHdXcv7xqssyMuN+xtAY4S8b3
s6X9frQsa7vQU5hrFT1vsJFRVCYljGU65xeo27Mu0kGWkkvjqp+SDZTJsZ/Cvpy6
os7/OeagvPakhrsy2T+yfelkHwWh8B82buS6xp0T/opYI2ruEN6PyTr7czbOk0r+
+F4DXoGfaALL3C9K2jQTWrA2a578VpjTBk/MHIANKg3iDrGPAspOykb5xk+6Lnn8
cOxfE7EiYqVP0veWnCYPfCo6Ol97xkCfqmKExw6QWK6iIKQo5Djvu10DNtPW68+K
P+lw44l77OhoBestMBY7n1BJVP2ARuEETw75t+tFpSBsM8WKSo7wNTUOKqi17d7B
HB7aQsNBj5DH3riEA+g7y0er1zSuqPkdScNh3DKZfLjNxWq8PoIj2waYsGdFbq12
2HQIGf2OcvQjpfg51nB2nL0sLtoZsgZ+bNSAml+5zI4grqiikb0=
=zl9q
- -END PGP SIGNATURE-

- --
- -Patrick
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.2.4
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJiDwBtACEJEBmfnf72/7r9FiEE8faSI4+8FmblpczUGZ+d
/vb/uv18aBAArH4Pe47hJnubJMGJ00Y5fgwZd6WxgQe7PillqeepIbl7BwBL
y+b3jVblXMMvZ3zrumEPOaw6uIOhA26u/vTWG0VLpIHrC9zyTUe+MDP+La1p
92FxmasXTyysiIg1sTmgVJqusfLrsbyRGPcn6Dw03u5a2jTVSGAd6XorLEz+
N2LIFq/Yu+qLl3ZXPW3W69I/GGjqV1iXydI6bmdltJGZPmIM3P7rOo7RFfth
0deHNWHzSypZWoOUOpLb9xDA6VdWiAtTkBTRGJrndy61mz02xa3IiDXYB3Yt
wN6p8cvqg6Cu0/BRU1EJygkyYHC2/SLe/YryA+Er4eEkZ7wO7VG0sBi1AGFa
hxGEayhR5tZGLLtC9xgXKkEEsihtbREBqzPM9B3zkkCeMl6/xJD9gTH68v+n
ENgkQ6QHRNb85GZN8Fd75QSEi6Helz00c1CVFd9PPvQlpFsucJo5R6orBt3y
KynGwZm/ToOIE0Jt+syGt2aMnM+fmoBP7053wd3jIwmr2lXk5ri18Cy8i57D
gj/JIUZA6CHmwewtq93MKZf/67HvFhNBDXBOdYUoFxe8wIpjSZvuOmAeQ9JC
VAZAH22hRz5/BJbxsbM7Xf2wl31kEFJpM+TxzADRMCme/0jT4UD5OTMhaAaM
a30hj1kYcj7q14Ujpv+HV14Iwnvsp66mu9w=
=e1ax
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 8.0.16 Released

2022-02-17 Thread Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.16. This is a security release.

All PHP 8.0 users are encouraged to upgrade to this version.

For source downloads of PHP 8.0.16 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/6fa7778121674f2e123f5ca91de4c224

php-8.0.16.tar.gz
SHA256 hash:
ce0ea32ff9c5af18cfb70197b40caf55824400dc8d5b4258a783ec9168baa5b1
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmIMHSQQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctY3D/4hLEwof2fE2xCslSbREGRtl7FpAW0m3GUw
w7E74m9Z+nqsWxxKS4tIXuFWxUddlekegs8VSyxUQel57H6Fq1FNrDNfI8CcDScC
zH0JBvY3CTQQCGYGg2xB6R6M/FSEFhjqbSgLmHPoib+m9OSAdxI452YnrBPODFdj
GriosG2VhVKt0+SjSL594NA7UhP0g5sV52aKICvoa0800ikHNHH7+NDxkd023T+j
cTWjwDFm2meQz5qTwUA8CCWg5F3d2qTq47//Q7ILf6PJ1Pw8VFoTKGLMTmaXv2BP
XUXcLqLqELs91p7V4Sj60go5jt27gncVR6cwirnTPA5C6hjLANFCgpAK+M132NaD
ANzt7Ff6WyER4FjenpUYqhGY5I8XVSrmpvXTAaV8ZZFLcbC0uS1qOQT7j9CKL6Q6
1EFZu3ojPuYXgWJyrHxetVbYyCzVMapEdSkaTIebDt6v22JRbesQEERY9xaaspBT
tERvCHawaOSDrxk/mFyTB3bWnTPTyR6eRm4wwD83sLa9L8JFlTF3OQnAZ4blQC+1
h1O+wX3sj+ZtweOT73KoiurExG2pclsu4UERCDvWKBZMWkQTaBsMf7q1GCu8va7x
3UQftW1dHuWIiYgu33XsvXYjGX/ZlB6Fq06W2p/PGOKgiOlY3JYRPjc/v42v6Umo
z8WZK8ahbg==
=obDa
-END PGP SIGNATURE-

php-8.0.16.tar.bz2
SHA256 hash:
f49f8181ee29463a0d23a0c65969e92d58fee8ac564df917cff58e48d65e1849
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmIMHSQQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhchSPD/4p8Kcv9yx0Zah8X0h+U+OtVCAIZytBEQdP
IdqERLF27zNY/H1g35jSzUwZfoxAjj/aCoB6J5JlyiPLynFvRvHSUCqjBLz1ZUR2
yLlvbNEZk3vcJr6eIcYHuDaPMAKhH3mVJz9NcHBLRQ9D1cf5CHVmWSe6aPpAebiz
/9261NXDV0LeDGvRcsCltvTB2Ogao+wYTw3FR/pzWto6khVqTND9cXgbipLFVCfb
fJe9fIiWd3lxl9joYhBTjtczSX+EB02vy32UnGOnaScSjPQvt5nMEq/c7gNDPWEu
b/180rgvjwtGP7Me1sKxt8tIziSsl1F7E/yzHfcxxbqH+6KYFxTWpugI2t8+8gl3
LfNwfDctEPv115jGuhgT2Ax6tVh91FIUZgUZ5wo52DVveHazGJcypgUnwsdm9dtU
TSjg8TEzTYdc9XmFBmEVesvwDh7R3poL1FIMu2Des67tCesb2OddZm50FwaqBUPt
LpAaBFhnDIuUPtKwXrd6Ry7RooqQRP6p4R+ufI+oluXJe67MquZp89NHny7Vslb1
PBeIZFo/ha25Ewz63cFRhDjtxkkEuSxJp3jxuD59E61ExpfAJYsf0QchTOzeyHHS
UFpoNGDs4/zYx9Etd+1xKZrPaetyPU/JmJO6f0cHs3fKgnkbK/CXMGrWkBYOJRc3
/TKzrIHzTA==
=P3Cf
-END PGP SIGNATURE-

php-8.0.16.tar.xz
SHA256 hash:
f27a2f25259e8c51e42dfd74e24a546ee521438ad7d9f6c6e794aa91f38bab0a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmIMHSUQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcsyED/9AmWycfv8b6e8CA7w68EMDpo2tRQD2Ox8+
1Lp//0EQLsUakhT+GDl64v/I1viwul9+YeFFWugI85y7wElBYtPqiQdCEBDuAmTf
MKYnCnVGdarBXZecm6q+neKVC3aSJtVriqqX1TM/DoAa8mFSOBl+KfA2vOFv8M8m
d8lhyL2O55eFAO6IhnaN/K/BuljOBUP05gsGRSGs+cyAVQMlOWZicvVh0UCR4lIe
oDqXk5N3P5NoIUC7SZMRLj7tTfTM1SL460HKuO228rgl52zN5yml4zmpsVAyGTXV
hg0dKcSZV3LBvOlQ3bjNOTRRnfJaDmbOWYUFok5tQOjJIeRAAhVwXXFSoSTOPJG7
HsoEJ7zJ9X0NaQDoGXJ23mVr+lgJE/CfOnB4UQiRSU9yUNzNW4mKQ+fKuiOMHp/B
KomgkUmffG06BmWD2o1bFaIhtITK3W4DNCeZ9m6oat7GcjhgwUxTUVy+3XiSpnc5
Xhc68IOIQBqE+zQpA6tQagEpkOiwywKHm3XarESrXGJL3p24bQTP/NFwh0oW24qQ
EtqPXgSh45ZvKCQQShRLQ5zOTD6MYMvKswE9kxfQxBX31mOHRFRK88Kr0LabBczR
NYi2/u7OXHje/OpoExdfRlPbA16+fEDk7a7vYThDDaQcgixyCnYOpJppRw2n1vtk
FNklJqKgGQ==
=GwT8
-END PGP SIGNATURE-

[PHP-DEV] [RFC] Undefined Variable Error Promotion

2022-02-17 Thread Mark Randall


Internals,

Following on from my previous thread, I think we are now in a position 
where we can begin formal discussions on an RFC to promote undefined 
variables to Error exceptions in PHP 9.0.


I present:

https://wiki.php.net/rfc/undefined_variable_error_promotion

I still intend to bring other error promotions forward, potentially in 
collaboration with other developers, but as this is the biggest change, 
and the most likely to attract a large number of comments, I thought it 
deserving of a standalone RFC.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 7.4.28 Released!

2022-02-17 Thread Derick Rethans

The PHP development team announces the immediate availability of PHP
7.4.28. This is a security release.

All PHP 7.4 users are encouraged to upgrade to this version.

For source downloads of PHP 7.4.28 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.


php-7.4.28.tar.gz
SHA256 hash: a04014cd1646b90547907e2e0ac5371594533960de317b6c7ac70bcb42db92fb
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmILqaEACgkQkQ3rRvU+
oxIDnA/7BnyqVko096GBQLZyJuh83bBCuJ9jHdHqA0Na2ULjGdqvKnU9urAa/gSj
CNqDrXmzfTZ6dSYs6iB4hEwHIEqD/xJvnZ/XptgoQsXZZNQQFzl3I0ZbyhLukfjA
boXLABKKN60mKG+r0C/D/mIlKJ7YGPQVvar4irnpzT3l1NYlfh9lygx0plCJcL67
bhxW+BbYN2jr7jaqHKr+KXju//tbLtOnlZWdCaBZp+VwVWaBFpAysj+Q82lsvhVe
6v8Mgx1Tn1NsHgvIkS3jWbyB7XGPBNeLTfe2dmOz5qYPaNvA/1oybogOZHIUef9N
AZCtfEcLGtNkhs7Ya1P9/7yNEEfIMdt6Fkp0oHTClML3PiMGXXl6TFW35fe0v8/9
PGWZ4T8PCfUM+FXPIOCN3Ds/JqpAYVZ8hpqU+W9Ro/8WWM3BxXedDtiDwLZ13BKE
cvdC/1ZTV2EdpwOqghwKQKLQ8qS6W6XqyYboL0G7Pye6wEIbETGXwsLiTHbdavrk
HLvoiqw9ljXCK9FDWUkTy6WNXWq+84FGR22V90pR9UGTQVMY8e6W0rscVM41Bo2I
hZvPROYrWyNPDLUpeFZnSDor8JYzYxJnM18FTQTYN+UN9uyF1xlgsAb5z3ee9Frm
ddGneV3TS5tho02A6ukA2c62P9WYn5f/UUuQtJc5FPmtg+NFQ1s=
=Ns5p
-END PGP SIGNATURE-

php-7.4.28.tar.bz2
SHA256 hash: 2085086a863444b0e39547de1a4969fd1c40a0c188eb58fab2938b649b0c4b58
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmILqaUACgkQkQ3rRvU+
oxKxSxAAvoUNXqVtu1cN+NCwURdPuSg1sfVuH2i6hGbVrlyO5P+3lSyqB2/YSfkz
6V6V8r3m06SqscePFzAVyUtPZYER11BmLjJtHuWX/LJTUlcrmAj0PPaKfOrV6avC
YBJXJsGHB1guARYosuwbXngyjFVHBulbQmD3AsMVEGaT8P6n8ROQYiP8+L1Y0SC1
gQkqaCwQuvRDC2h5Ovj00Dx7uWo3hsmXJoadTRjsXPt3IInqIMaFa9oyhns++UPG
f36vmPFbaEGv/qbqkbUC7iXOiEhXTSTq1LAhwJvkmAcZFIhg2cM6c5W7iuMASSGp
jN8XiUcuGwAw5eUtAFeWW5V8j+TdD+gM/jjmd0U91vJCTbcMQC8AvJYE2cyTdj0E
/eeo3pmtVsiPkIHtQYJUF2WjK8d7hA/otJv0Wxekf3aa/Gbt9R0K/h66+gyr5Lkq
hMygfhOyepqcW2RhmsSXGu4ctVV1OOuXBThfEPWzc/jCkx0eSaZnaINYNJKJ1c1r
Fc85IiFIwakw/3sTEcqxP33creVevEzmy3Ao0DFmvw6O6TCupGxtbTuhxdoAbu9E
dv0l3N2kKFklB4kD6IWQj/5CSQ9RzAMfhtCTb9cUOhAn6zQZQRR3E/dcAojOKhMU
WbGYD2Et6YKG7i117QoXazdPh69jnBPnqWO05tH4SQabR8urjjc=
=6AQl
-END PGP SIGNATURE-

php-7.4.28.tar.xz
SHA256 hash: 9cc3b6f6217b60582f78566b3814532c4b71d517876c25013ae51811e65d8fce
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmILqaUACgkQkQ3rRvU+
oxKwgw//Yzh0mYFFl4jcxJsXKRAl+6yjsN0NCXRjX58Vf72r0d3uzz6LqE4Gcit3
WGP7cG17hXJ5FvYyBp8/1c0pz1vP87TN42Vm+YWD4nQyMqx8qSOICTAFa0AFDFvN
4P/SD97/USsJVma4HYuBZQyCnL2rg6puw3YEG3JEjSWd3mOkJFsP1QhIjT4zV0UY
N53a7Rx2ocKwfTqd8HivxJ//nTwygTmqIC2810s5ADNhejZGU74O4zOFOjkuH8LX
bzdOn38EKkcBTJdwGBKgqvY3nEFeza5kIfybNcWN1oik/br+MXTXHQHoZTbuasHf
mDqkhMHIOrkRa5Av0T6PQp/7T9AY5TC+KFQQ/fCTMDyk97udg/jy0miOkRj97K/n
4ioareYF8Jnyknp6GebFyJItoVv4RwhagviuIBN7Np26TdLINRKAXozQTyIQkVHv
GIZQwx5gdTdzV2qYfIccXKx3yIbIs5qi6idfbI4GQDZ2D0Hwro64RMXyve0Wx9CV
thszN2A5EdiGsyzxg2HcYJGYmedROSzscu/MOi1EXv6k95bnG+7W1Z7h81rMrFTz
PfAMtIi39oMoC9VkOuWIDzJRkOiGUjX1I82hqCcMdY66pfg0dbntkG8Xe0UMg1WS
l2IR4zTfQx/Y1f00r7LPlc5i0j9ts3zQrwrD4uGC304VVf0MubA=
=muVN
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

2022-02-17 Thread Tim Düsterhus


Hi

On 2/17/22 08:37, Go Kudo wrote:

The following points have been fixed:

- `nextByteSize(): int` has been removed from Random\Engine
- If the width of the RNG is statically defined, it will now be used
preferentially
- Added Xoshiro256StarStar
- Fixed an endianness issue

And updated RFC

https://wiki.php.net/rfc/rng_extension

[...]
This seems to have solved the whole problem. How about it?


Awesome, this is feeling much much better now. As you might've seen I've 
made some comments on GitHub regarding implementation bugs.


I have two more conceptional questions:

---

1)

However I believe you did not answer my question regarding the following 
and that's something that should be clear in the RFC and documentation:


getBytes(8))); // string(16) "c510c70f6daff2b3"
var_dump(\bin2hex($r2->getBytes(4) . $r2->getBytes(4))); // 
string(16) "c510c70fea4c3647"



In this example I get 8 bytes from the randomizer. One time by getting 
all 8 bytes at once, the second time by getting 4 bytes and then another 
4 bytes.


I think that both lines should result in the same output, because in 
both cases I am getting 8 bytes, without any other operations that might 
affect the engine state in between. As a user I should not be required 
to know how the Randomizer works internally (by always getting 8 bytes 
from the engine and throwing away unused bytes).


If you disagree and think this is the correct behavior then this should 
be documented accordingly in the RFC. If you agree, then this should be 
fixed and a testcase be added.


---

2)

This ties into (1): Currently any additional bytes returned by the 
engine are silently ignored. Either the bytes should be processed in 
full, or an error emitted if the returned bytestring is too long.


Consider the attached test case with a Sha1-based RNG. If I grab 20 
bytes (the length of a SHA-1 hash) from the Randomizer then the 
'generate()' function will be called 3 times, despite it returning 
sufficient bytes on the first attempt. If I want to make sure that no 
bytes are wasted, then I need to implement a pretty complex construction 
(Sha1_2) to always return exactly 8 bytes.


Best regards
Tim Düsterhus<>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Setting to disable the "Undefined array index" warning

2022-02-17 Thread Mark Randall


On 15/02/2022 12:31, Nicolas BADIA wrote:

As I’m not ready to spend weeks upgrading our codebase because our coding style 
is not supported by the community, I’m looking at alternatives.



I don't think you'll be in luck, and should plan to get ready.

As to the specific behaviour:

If anything this behaviour will get tighter over time, and it's entirely 
possible that in a later major release it will throw an error (although 
that's not being proposed right now).


From my conversations, there is little apetite to add additional INI 
based controls for engine behaviour, as they are believed to lead to 
inconsistencies that harm the ecosystem, rather than enhance it.


Forking PHP to avoid resolving ambiguities in your code seems like it 
would be a false economy.


Ideally you should bring your code up-to-date with what is expected, but 
if you are unwilling or unable to do that, you may instead wish to stay 
on an older version that hax more lax behaviour, and purchase LTS from 
the likes of Zend.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

[PHP-DEV] PHP 8.1.3 Released

[PHP-DEV] PHP 8.0.16 Released

[PHP-DEV] [RFC] Undefined Variable Error Promotion

[PHP-DEV] PHP 7.4.28 Released!

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

[PHP-DEV] Re: Setting to disable the "Undefined array index" warning

9 matches

Site Navigation

Mail list logo

Footer information