random: Improve the output quality of RANDOM_SEED() (#13730)

* random: Improve the output quality of RANDOM_SEED()

Previously 4 consecutive calls to `RANDOM_SEED()` each for 4 diffe

random: Improve the output quality of RANDOM_SEED() (#13730)

* random: Improve the output quality of RANDOM_SEED()

Previously 4 consecutive calls to `RANDOM_SEED()` each for 4 different CLI
requests resulted in:

$ sapi/cli/php test.php
2c13e9fde9caa
2c13e9fd1d6b0
2c13e9fd4de34
2c13e9fd1610e
$ sapi/cli/php test.php
2c1436764fe07
2c14367621770
2c143676c0bf6
2c143676e02f5
$ sapi/cli/php test.php
2c144995a0626
2c14499590fe2
2c144995c65db
2c14499536833
$ sapi/cli/php test.php
2c145cb30860b
2c145cb3ec027
2c145cb33b4ca
2c145cb38ff63

Now they result in:

$ sapi/cli/php test.php
6796973ace1b5f3d
1913daf5c158cb4b
255dbf24237bc8c9
7c3ba22e60f35196
$ sapi/cli/php test.php
afb7cc9ba9819cd2
3e01a71b91ad020c
6b718364d3ef108
bdcd17beeb4b31d2
$ sapi/cli/php test.php
53d36eb9b83f8788
4381c85e816187aa
2e9b32ee9898e71e
31d15c946842bddb
$ sapi/cli/php test.php
2037a3cba88114b4
ba0b0d93a9bb43aa
e13d82d2421269e2
191de474f3292240

* tree-wide: Replace GENERATE_SEED() by php_random_generate_fallback_seed()

* random: Fix NTS build

* random: Fix Windows build

show more ...

random: Clean Up the Mt19937 state struct (#13577)

* random: Make Mt19937's `mode` field an enum

* random: Reorder the `php_random_status_state_mt19937` struct

Empirical te

random: Clean Up the Mt19937 state struct (#13577)

* random: Make Mt19937's `mode` field an enum

* random: Reorder the `php_random_status_state_mt19937` struct

Empirical testing did not show any differences in performance, but it makes
sense to me to put the `count` field (which is accessed for every invocation of
Mt19937) at the beginning of the struct, keeping it near the values from the
state array that are returned first, resulting in only a single cache line load
if only a small amount of numbers are requested.

It naturally follows to also put the `mode` field there and move the
humongous state array to the end.

* random: Remove the `MT_N` constant

`MT_N` is an awfully generic name that bleeds into every file including
`php_random.h`. As it's an implementation detail, remove it entirely to keep
`php_random.h` clean.

To prevent the state struct from diverging from the implementation, the size of
the state vector is statically verified. Furthermore there are phpt tests
verifying the Mt19937 output across a reload, revealing when the state vector
is reloaded too early or too late.

show more ...

random: Clean up seeding API (#13540)

* random: Expose xoshiro256**'s seeding functions

* random: Expose pcgoneseq128xslrr64's seeding functions

* random: Expose Mt19937's

random: Clean up seeding API (#13540)

* random: Expose xoshiro256**'s seeding functions

* random: Expose pcgoneseq128xslrr64's seeding functions

* random: Expose Mt19937's seeding functions

* random: Expose CombinedLCG's seeding functions

* random: Call php_random_mt19937_seed32 to seed the global Mt19937

This avoids the function pointer indirection and improves type safety.

* random: NULL the generic seeding function

Different engines work quite differently, it is not useful to attempt to seed
them in a generic way using a 64 bit integer. As an example Mt19937 completely
ignores the upper 32 bits.

* random: Remove the `seed` member from `php_random_algo`

See the explanation in the previous commit for the reasoning. This member is
unused since the previous commit and was not consistently available even before
that (specifically for the Secure engine).

* UPGRADING.INTERNALS

* random: Remove useless cast in `php_mt_srand()`

show more ...

random: Adjust `status` to `state` (#13521)

* random: Rename `status` local to `state`

* random: Rename `php_random_algo_with_state`'s `status` member to `state`

random: Pass algorithm and state together as `php_random_algo_with_state` (#13350)

* random: Remove `php_random_status`

Since 162e1dce9870168cb8c65c013f2b5a510b6536b1, the `php_rand

random: Pass algorithm and state together as `php_random_algo_with_state` (#13350)

* random: Remove `php_random_status`

Since 162e1dce9870168cb8c65c013f2b5a510b6536b1, the `php_random_status` struct
contains just a single `void*`, resulting in needless indirection when
accessing the engine state and thus decreasing readability because of the
additional non-meaningful `->state` references / the local helper variables.

There is also a small, but measurable performance benefit:

<?php
$e = new Random\Engine\Xoshiro256StarStar(0);
$r = new Random\Randomizer($e);

for ($i = 0; $i < 15; $i++)
var_dump(strlen($r->getBytes(100000000)));

goes from roughly 3.85s down to 3.60s.

The names of the `status` variables have not yet been touched to keep the diff
small. They will be renamed to the more appropriate `state` in a follow-up
cleanup commit.

* Introduce `php_random_algo_with_state`

show more ...

random: Do not hardcode the target type when invoking the CSPRNG (#13308)

Instead derive the number of bytes to retrieve from the variable that is being
filled.

random: Move CSPRNG API into php_random_csprng.h (#13290)

This allows consumers of just the CSPRNG to include a much smaller header. It
also allows to verify at a glance whether a source

random: Move CSPRNG API into php_random_csprng.h (#13290)

This allows consumers of just the CSPRNG to include a much smaller header. It
also allows to verify at a glance whether a source file might use non-secure
randomness.

This commit includes the new header wherever the CSPRNG is used, possibly
replacing the inclusion of php_random.h if nothing else is used, but also
includes it in the main php_random.h header for compatibility.

Somewhat related to 45f8cfaf104f504340b0073b9736bb50a88d70a1,
2b30f18708b4f73d2c1d29d3a92a606ebdc5ac4c, and
b14dd85dca3b67a5462f5ed9b6aa0dc22beb615c.

show more ...

random: Call int-seeding functions directly

As the `__construct()` implementation is engine-specific anyway, we know what
engine were dealing with and can just call the seeding function

random: Call int-seeding functions directly

As the `__construct()` implementation is engine-specific anyway, we know what
engine were dealing with and can just call the seeding function directly
instead of going through a function pointer.

This likely improves construction performance a little, but I did not measure.

show more ...

random: Optimize data flow for the `generate` function of native engines (#13043)

Instead of returning the generated `uint64_t` and providing the size (i.e. the
number of bytes of the ge

random: Optimize data flow for the `generate` function of native engines (#13043)

Instead of returning the generated `uint64_t` and providing the size (i.e. the
number of bytes of the generated value) out-of-band via the
`last_generated_size` member of the `php_random_status` struct, the `generate`
function is now expected to return a new `php_random_result` struct containing
both the `size` and the `result`.

This has two benefits, one for the developer:

It's no longer possible to forget setting `last_generated_size` to the correct
value, because it now happens at the time of returning from the function.

and the other benefit is for performance:

The `php_random_result` struct will be returned as a register pair, thus the
`size` will be directly available without reloading it from main memory.

Checking a simplified version of `php_random_range64()` on Compiler Explorer
(“Godbolt”) with clang 17 shows a single change in the resulting assembly
showcasing the improvement (https://godbolt.org/z/G4WjdYxqx):

- add rbp, qword ptr [r14]
+ add rbp, rdx

Empirical testing confirms a measurable performance increase for the
`Randomizer::getBytes()` method:

<?php
$e = new Random\Engine\Xoshiro256StarStar(0);
$r = new Random\Randomizer($e);

var_dump(strlen($r->getBytes(100000000)));

goes from 250ms (before the change) to 220ms (after the change). While
generating 100 MB of random data certainly is not the most common use case, it
confirms the theoretical improvement in practice.

show more ...

Deprecate MT_RAND_PHP (#11560)

see https://wiki.php.net/rfc/deprecations_php_8_3#mt_rand_php

Fix pre-PHP 8.2 compatibility for php_mt_rand_range() with MT_RAND_PHP (#9839)

* Fix pre-PHP 8.2 compatibility for php_mt_rand_range() with MT_RAND_PHP

As some left-over comments in

Fix pre-PHP 8.2 compatibility for php_mt_rand_range() with MT_RAND_PHP (#9839)

* Fix pre-PHP 8.2 compatibility for php_mt_rand_range() with MT_RAND_PHP

As some left-over comments indicated:

> Legacy mode deliberately not inside php_mt_rand_range()
> to prevent other functions being affected

The broken scaler was only used for `php_mt_rand_common()`, not
`php_mt_rand_range()`. The former is only used for `mt_rand()`, whereas the
latter is used for `array_rand()` and others.

With the refactoring for the introduction of ext/random `php_mt_rand_common()`
and `php_mt_rand_range()` were accidentally unified, thus introducing a
behavioral change that was reported in FakerPHP/Faker#528.

This commit moves the checks for `MT_RAND_PHP` from the general-purpose
`range()` function back into `php_mt_rand_common()` and also into
`Randomizer::getInt()` for drop-in compatibility with `mt_rand()`.

* [ci skip] NEWS for `MT_RAND_PHP` compatibility

show more ...

random: Validate that the arrays do not contain extra elements when unserializing (#9458)

* Apply `var_dump()` in 02_engine/all_serialize_error.phpt

This ensures that an undetected

random: Validate that the arrays do not contain extra elements when unserializing (#9458)

* Apply `var_dump()` in 02_engine/all_serialize_error.phpt

This ensures that an undetected serialization error is clear identifiable in the output.

* random: Validate that the arrays do not contain extra elements when unserializing

show more ...

Fix GH-9186 @strict-properties can be bypassed using unserialization (#9354)

* Emit deprecation warnings when adding dynamic properties to classes during unserialization - this will become a

Fix GH-9186 @strict-properties can be bypassed using unserialization (#9354)

* Emit deprecation warnings when adding dynamic properties to classes during unserialization - this will become an Error in php 9.0.
(Adding dynamic properties in other contexts was already a deprecation warning - the use case of unserialization was overlooked)
* Throw an error when attempting to add a dynamic property to a `readonly` class when unserializing
* Add new serialization methods `__serialize`/`__unserialize` for SplFixedArray to avoid creating deprecated dynamic
properties that would then be added to the backing fixed-size array
* Don't add named dynamic/declared properties (e.g. $obj->foo) of SplFixedArray to the backing array when unserializing
* Update tests to declare properties or to expect the deprecation warning
* Add news entry

Co-authored-by: Tyson Andre <tysonandre775@hotmail.com>

show more ...

Fix undefined behavior of MT_RAND_PHP if range exceeds ZEND_LONG_MAX (#9197)

RAND_RANGE_BADSCALING() invokes undefined behavior when (max - min) >
ZEND_LONG_MAX, because the intermediate

Fix undefined behavior of MT_RAND_PHP if range exceeds ZEND_LONG_MAX (#9197)

RAND_RANGE_BADSCALING() invokes undefined behavior when (max - min) >
ZEND_LONG_MAX, because the intermediate `double` might not fit into
`zend_long`.

Fix this by inlining a fixed version of the macro into Mt19937's range()
function. Fixing the macro itself cannot be done in the general case, because
the types of the inputs are not known. Instead of replacing one possibly broken
version with another possibly broken version, the macro is simply left as is
and should be removed in a future version.

The fix itself is simple: Instead of storing the "offset" in a `zend_long`, we
use a `zend_ulong` which is capable of storing the resulting double by
construction. With this fix the implementation of this broken scaling is
effectively identical to the implementation of php_random_range from a data
type perspective, making it easy to verify the correctness.

It was further empirically verified that the broken macro and the fix return
the same results for all possible values of `r` for several distinct pairs of
(min, max).

Fixes GH-9190
Fixes GH-9191

show more ...

Add ext/random Exception hierarchy (#9220)

* Add Random\Random{Error,Exception} and Random\BrokenRandomEngineError

* Throw BrokenRandomEngineError

* Throw RandomException o

Add ext/random Exception hierarchy (#9220)

* Add Random\Random{Error,Exception} and Random\BrokenRandomEngineError

* Throw BrokenRandomEngineError

* Throw RandomException on seeding failure

* Throw RandomException when CSPRNG fails

* Remove unused include from ext/random/engine_combinedlcg.c

* Remove unused include from ext/random/engine_secure.c

* Remove unused include from ext/random/random.c

* [ci skip] Add ext/random Exception hierarchy to NEWS

* [ci skip] Add the change of Exception for random_(int|bytes) to UPGRADING

show more ...

Clean up nested exceptions without value-add in ext/random (#9211)

* Remove exception in Randomizer::shuffleBytes()

The only way that `php_binary_string_shuffle` fails is when the e

Clean up nested exceptions without value-add in ext/random (#9211)

* Remove exception in Randomizer::shuffleBytes()

The only way that `php_binary_string_shuffle` fails is when the engine itself
fails. With the currently available list of engines we have:

- Mt19937 : Infallible.
- PcgOneseq128XslRr64: Infallible.
- Xoshiro256StarStar : Infallible.
- Secure : Practically infallible on modern systems.
Exception messages were cleaned up in GH-9169.
- User : Error when returning an empty string.
Error when seriously biased (range() fails).
And whatever Throwable the userland developer decides to use.

So the existing engines are either infallible or throw an Exception/Error with
a high quality message themselves, making this exception not a value-add and
possibly confusing.

* Remove exception in Randomizer::shuffleArray()

Same reasoning as in the previous commit applies.

* Remove exception in Randomizer::getInt()

Same reasoning as in the previous commit applies.

* Remove exception in Randomizer::nextInt()

Same reasoning as in the previous commit applies, except that it won't throw on
a seriously biased user engine, as `range()` is not used.

* Remove exception in Randomizer::getBytes()

Same reasoning as in the previous commit applies.

* Remove exception in Mt19937::generate()

This implementation is shared across all native engines. Thus the same
reasoning as the previous commits applies, except that the User engine does not
use this method. Thus is only applicable to the Secure engine, which is the
only fallible native engine.

* [ci skip] Add cleanup of Randomizer exceptions to NEWS

show more ...

Unify ext/random unserialize errors with ext/date (#9185)

* Unify ext/random unserialize errors with ext/date

- Use `Error` instead of `Exception`.
- Adjust wording.

*

Unify ext/random unserialize errors with ext/date (#9185)

* Unify ext/random unserialize errors with ext/date

- Use `Error` instead of `Exception`.
- Adjust wording.

* Make `zend_read_property` silent in `Randomizer::__unserialize()`

Having:

> Error: Typed property Random\Randomizer::$engine must not be accessed before
> initialization

is not a value-add in this case.

* Insert the actual class name in the unserialization error of Engines

* Revert unserialization failure back to Exception from Error

see https://news-web.php.net/php.internals/118311

show more ...

Improve phrasing in argument value errors in ext/random (#9206)

This rephrases the error message for argument errors to be a proper English
sentence.

Co-authored-by: Máté Kocsis

Improve phrasing in argument value errors in ext/random (#9206)

This rephrases the error message for argument errors to be a proper English
sentence.

Co-authored-by: Máté Kocsis <kocsismate@woohoolabs.com>

show more ...

[ci skip] Improve error message of an engine fails to seed from the CSPRNG (#9160)

Use ValueError if an invalid mode is passed to Mt19937 (#9159)

Remove `->last_unsafe` from php_random_status (#9132)

Whenever ->last_unsafe is set to `true` an exception has been thrown. Thus we
can replace the check for `->last_unsafe` with a check

Remove `->last_unsafe` from php_random_status (#9132)

Whenever ->last_unsafe is set to `true` an exception has been thrown. Thus we
can replace the check for `->last_unsafe` with a check for `EG(exception)`
which is a much more natural way to ommunicate an error up the chain.

show more ...

[ci skip] Update EXTENSIONS and Author(s) in ext/random (#9074)

php.net account is better suited for this cases.

Implement Random Extension

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