[PHP-DEV] Re: PHP 7.4.28 Released!

[Christoph M. Becker]

On 18.02.2022 at 16:02, Jan Ehrhardt wrote:

> Derick Rethans in php.internals (Thu, 17 Feb 2022 14:42:47 + (GMT)):
>> The PHP development team announces the immediate availability of PHP
>> 7.4.28. This is a security release.
>
>> Windows downloads:
>
> 7.4.28 is not there. 7.4.27 is there. And even 7.3.33 is still there.

We're having some issues with the PHP 7.4 build VM.  I'm confident that
the PHP 7.4.28 builds are available soonish.

I'm going to remove the 7.3 downloads right away.

Thanks for reporting!

--
Christoph M. Becker

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

[PHP-DEV] Re: PHP 7.4.28 Released!

[Jan Ehrhardt]

Derick Rethans in php.internals (Thu, 17 Feb 2022 14:42:47 + (GMT)):
>The PHP development team announces the immediate availability of PHP
>7.4.28. This is a security release.

>Windows downloads:

7.4.28 is not there. 7.4.27 is there. And even 7.3.33 is still there.
-- 
Jan

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

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

[Rowan Tommins]

On 18/02/2022 12:31, Mark Randall wrote:
I would claim that the unary operators behave slightly different, if 
it were a case of cooerce to zero, the behaviour of null++ and null-- 
would be expected to be the same as operating on 0, but it's not.


null++ is allowed, but null-- returns null, and its value afterwards 
is null.


https://3v4l.org/Bnb2D



It is "--" that is the odd one out here, not "++". Every other 
arithmetic operator in the language treats null as equivalent to 0.


As far as I can tell, the fact that "$a--" behaves differently from "$a 
-= 1" is an implementation bug that's been around so long it's become 
documented behaviour. I tried to propose changing it, but the reaction 
degenerated into personal abuse, so I abandoned it.



If anything, it's the fact that $a++ is NOT a special case that means 
it will be affected by this proposal.


It is intended to be affected by this proposal. 



I didn't say it wasn't intentional, I said it wasn't special; the exact 
same behaviour applies to about a dozen operators which have to read the 
current value before writing.


Concatenation, for instance, treats null as an empty string, so this 
currently works (with a Warning) even if $message is undefined:


$message .= "Another thing happened\n";


Regards,

--
Rowan Tommins
[IMSoP]

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

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

[Mark Randall]

On 18/02/2022 10:50, Rowan Tommins wrote:
Other than an optimised implementation, there's nothing particularly 
special about the ++ operator's handling of null, it behaves the same as 
any other arithmetic operator:


I would claim that the unary operators behave slightly different, if it 
were a case of cooerce to zero, the behaviour of null++ and null-- would 
be expected to be the same as operating on 0, but it's not.


null++ is allowed, but null-- returns null, and its value afterwards is 
null.


https://3v4l.org/Bnb2D

If anything, it's the fact that $a++ is NOT a special case that means it 
will be affected by this proposal.


It is intended to be affected by this proposal.

--
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

[Rowan Tommins]

On 17/02/2022 23:28, Mark Randall wrote:

I present:

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



It would be good to have a "Scope" or "Unaffected Functionality" section 
here, because there are a number of closely related things which were 
also raised from Notice to Warning in 8.0:


- undefined array keys
- undefined object properties
- array access on a non-array
- property access on a non-object

I think it is sensible to discuss those separately, but it would be good 
to make that clear.



Similarly, it would be good to have more discussion of what "accessing" 
means, as the current examples are quite narrow, only showing direct use 
and the ++ operator. Other functionality potentially affected:


- passing the variable to a function, presumably excluding by-reference 
parameters which don't currently warn
- all the combined assignment operators - 
https://www.php.net/manual/en/language.operators.assignment.php
- the array append operator ($a[] = 42;) does NOT currently give an 
undefined variable Warning

- variable variables, e.g. "$b = 'a'; echo $$b;"
- the compact() pseudo-function

There's probably others that I've missed.


Regards,

--
Rowan Tommins
[IMSoP]

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

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

[Rowan Tommins]

On 18/02/2022 08:51, Mark Randall wrote:
The only reason this works at all is because an undefined variable 
read falls back to null, and the increment operator is hardcoded to 
treat null++ as 1. 



Other than an optimised implementation, there's nothing particularly 
special about the ++ operator's handling of null, it behaves the same as 
any other arithmetic operator:


- Reading an undefined variable gives null
- Coercing null to an integer gives 0
- Adding 1 to 0 gives 1

So the following all have the same result:

unset($a); $a = $a + 1;
unset($a); $a += 1;
unset($a); $a++;
unset($a); ++$a;


If anything, it's the fact that $a++ is NOT a special case that means it 
will be affected by this proposal.



Regards,

--
Rowan Tommins
[IMSoP]

--
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

[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 primary issue here is that the engines are expected to 
return an uint64_t, instead of a buffer with raw bytes. This requires 
you to perform many conversions between the uint64 and the raw buffer:


When calling Randomizer::getBytes() for a custom engine the following 
needs to happen:


- The Engine returns a byte string.
- This bytestring is then internally converted into an uint64_t.
- Then calling Randomizer::getBytes() this uint64_t needs to be 
converted back to a bytestring.


To avoid those conversations without sacrificing too much performance it 
might be possible to return a struct that contains a single 4 or 8-byte 
array:


struct four_bytes {
unsigned char val[4];
};

struct four_bytes r;
r.val[0] = (result >> 0) & 0xff;
r.val[1] = (result >> 8) & 0xff;
r.val[2] = (result >> 16) & 0xff;
r.val[3] = (result >> 24) & 0xff;

return r;

.val can be treated as a bytestring, but it does not require dynamic 
allocation. By doing that the internal engines (e.g. Xoshiro) would be 
consistent with the userland engines.



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 don't think it's a good idea to add a size parameter to generate().


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?


*I* don't need anything. I'm just trying to think of use-cases and 
edge-cases. Basically: What would a user attempt to do and what would 
their expectations be?


I'm not saying that this buffering *must* be implemented, but this is 
something we need to think about. Because changing the behavior later is 
pretty much impossible, as users might rely on a specific behavior for 
their seeded sequences. The behavior might also need to be part of the 
documentation.


Basically what we need to think about is what guarantees we give. As an 
example:


1. Calling Engine::generate() with the same seed results in the same 
sequence (This guarantee we give, and it is useful).
2. Calling Randomizer::getInt() with the same seeded engine results in 
the same numbers for the same parameters (I think this also is useful).
3. Calling Randomizer::getBytes() with the same seeded engine results in 
the same byte sequence (This is something we are currently discussing).
4. Calling Randomizer::getBytes() simply concatenates the raw bytes 
retrieved by the Engine (This ties into (3)).
5. Calling Randomizer::shuffleArray() with the same seeded engine 
results in the same result for the same string (This one is more 
debatable, because then we must maintain the exact same shuffleArray() 
implementation forever).


All these guarantees should be properly documented within the RFC. The 
RFC template (https://wiki.php.net/rfc/template) says:


>  Remember that the RFC contents should be easily reusable in the PHP 
Documentation.


So by thinking about this now and putting it in the RFC, the 
explanations can easily be copied into the documentation if the RFC 
passes the vote.


One should not need to look into the implementation to understand how 
the Engines and the Randomizer is supposed to work.



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



If there's bias in specific bits or bytes of the generated number then 
getBytes(32) will already be biased even without buffering, as the raw 
bytes are what's of interest here. It does not matter if they are at the 
1st or 4th position (for a 32-bit engine).


Best regards
Tim Düsterhus

--
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

[Tim Düsterhus]

Hi

On 2/18/22 04:05, Go Kudo wrote:

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);
```


Personally I'd say by using the engine itself or using a different 
Randomizer it's clear that any kind of guarantees regarding the result 
no longer hold, because the state will be modified.


I've also seen your other email and will reply to it as well.

Best regards
Tim Düsterhus

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

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

[Mark Randall]

On 18/02/2022 07:48, Robert Landers wrote:

Just out of curiosity, why is the 3rd case being included here? Is it just
because it's currently a warning > When I first taught PHP in 2011, I was told

> post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1`


This is not the case, there is no isset($var) involved - specficially 
isset($var) would first check if a variable exists and is not null 
(ISSET_ISEMPTY_CV), it is designed to handle undefined variables, where 
as most things are not.


Before the increment can happen, the value in the variable must first be 
read. This leads to the E_WARNING for accessing an undefined variable 
just like any other, which this RFC seeks to prohibit.


The value is then copied internally, the original value is 
incrementeted, and the unchanged copy is returned (its value before 
incrementing).


The only reason this works at all is because an undefined variable read 
falls back to null, and the increment operator is hardcoded to treat 
null++ as 1.


That's why if you do this:

$x = $foo++;
var_dump($x);

You get:

Warning: Undefined variable $foo in  on line 3
NULL

Mark Randall

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