Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117056
MIME-Version: 1.0
References: <CAMs36HcsGqNanQaro_VTkK_VKHNg-jqtshXpW-aCxdqpxHjMdw@mail.gmail.com>
 <41a1b458-4941-f34e-f1b4-e25b3298b80a@bastelstu.be> <CAMs36Hc4GCPUp2m+6N1LTP+hPrUv15iZF2QTCHBuAm+KDyXgfw@mail.gmail.com>
 <553ba7ca-3821-c2d9-f88f-b216013a887b@bastelstu.be> <a2683304-542f-e63a-e35f-04e5bb75f5d1@bastelstu.be>
 <CAMs36Hc+W_GkO4W+FB=ySFvc79DYy+M3TaT5qL0Ap9NwmY=6dQ@mail.gmail.com>
 <2c667812-88c8-0b7b-3558-561a1348d0b2@bastelstu.be> <CAMs36HctoKykr=aSVCr_DtFEpeF1fZke5LGCOFu_-oQEzL06Ug@mail.gmail.com>
 <a94b1b01-dd9c-bb62-01ab-34c16c3d46cb@bastelstu.be> <CAMs36HcVYNVB+mukx27Z90+5DtiHz1JO0i7qF+kP6UaML-y3ZQ@mail.gmail.com>
 <5f496cf9-8754-b009-9cb5-b978222b2249@bastelstu.be> <CAMs36HdSf8Mh9Mugwvb643xNfLnpZQ0RAvV_ZuS11vQzQRTmZA@mail.gmail.com>
 <cc43d1ce-8807-c0fd-94a4-514ebedea661@bastelstu.be> <CAMs36HcC7O7YR6VVybw=ChPrWWcWjnCTxR6_=5scFy0+ksZEaA@mail.gmail.com>
 <a1369ca5-9d27-8151-300d-73b90cd584d3@bastelstu.be>
In-Reply-To: <a1369ca5-9d27-8151-300d-73b90cd584d3@bastelstu.be>
Date: Fri, 18 Feb 2022 12:05:58 +0900
Message-ID: <CAMs36He=ODRTXPtADY85WWSffxYjDgRDWyVWzeOPH6Hm4y_PZg@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000147ab405d8422ac2"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0
From: g-kudo@colopl.co.jp (Go Kudo)

--000000000000147ab405d8422ac2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B42=E6=9C=8817=E6=97=A5(=E6=9C=A8) 19:25 Tim D=C3=BCsterhus <tim=
@bastelstu.be>:

> 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:
>
>      <?php
>
>      use Random\Engine\Xoshiro256StarStar;
>      use Random\Randomizer;
>
>      $g1 =3D new Xoshiro256StarStar(1);
>      $g2 =3D clone $g1;
>      $r1 =3D new Randomizer($g1);
>      $r2 =3D new Randomizer($g2);
>
>      var_dump(\bin2hex($r1->getBytes(8))); // string(16) "c510c70f6daff2b=
3"
>      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=C3=BCsterhus


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
<?php

$engine =3D new \Random\Engine\Xoshiro256StarStar(1234);
$randomizer =3D new Randomizer($engine);

// Retrieve only 16 bits (the remaining 48 bits will be buffered in
Randomizer)
$str =3D $randomizer->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 =3D $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

--000000000000147ab405d8422ac2--