Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117301
MIME-Version: 1.0
References: <CAMs36Hco05vXydtM8qUfpcDkj6oKYufifAr-gOr573OwmVtimA@mail.gmail.com>
 <540c90b6-39cc-8cae-7912-602e5bf559c6@bastelstu.be>
In-Reply-To: <540c90b6-39cc-8cae-7912-602e5bf559c6@bastelstu.be>
Date: Fri, 11 Mar 2022 20:10:53 +0900
Message-ID: <CAMs36HcgzXNs8T=wsH-Nt0HTt3QUxLNm5JgF7quf5NKasU2v3A@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000f8431705d9ef62e8"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 5.x
From: g-kudo@colopl.co.jp (Go Kudo)

--000000000000f8431705d9ef62e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B43=E6=9C=8810=E6=97=A5(=E6=9C=A8) 3:57 Tim D=C3=BCsterhus <tim@=
bastelstu.be>:

> Hi
>
> On 3/9/22 11:48, Go Kudo wrote:
> > Proposed RFCs and implementations have been reorganized. The main chang=
es
> > are as follows
> >
> > https://wiki.php.net/rfc/rng_extension
> > https://github.com/php/php-src/pull/8094
> >
>
> I've compared the RFC against the implementation once more:
>
> - The RFC should clarify that returning an empty string in
> Engine::generate() is not allowed.
> - The corresponding test
> 'ext/random/tests/03_randomizer/user_unsafe.phpt' should verify not just
> an exception is thrown, but also the exception message (I'll add a
> review comment).
>
> - PCG64 effectively has 256 Bits of internal state (128 Bits for 's' and
> 128 Bits for 'inc'), but it only accepts 128 Bits for 's'. 'inc' cannot
> be provided by the user. The purpose of 'inc' is not entirely clear to
> me, but the user likely should be able to specify it for full
> reproducibility.
> - The default initialization of PCG64 with a null seed will fill 'inc',
> not 's'. This likely is a bug? At least it's inconsistent with the
> previous point.
>
> - The RFC is missing an explanation of the guarantees the implementation
> will (or will not) make. This is important for the user if they are
> relying on reproducibility of the sequences and outputs. The more
> guarantees we give, the less can be changed in the future. I've
> previously mentioned that in the thread for '4.x':
> https://externals.io/message/117026#117061
>
> Best regards
> Tim D=C3=BCsterhus
>

Hi Tim

Sorry, I must have missed some of your emails.

We will make corrections to the areas you pointed out. I will reply to your
email first as I am not familiar with English and it may take a little time=
.

Thank you!

--000000000000f8431705d9ef62e8--