Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115939
MIME-Version: 1.0
References: <CABTDVhBRpD=nWBk2xGLEmdcWwOzCeqGeqH5vLSugPFOeEN9Mog@mail.gmail.com>
 <CAF+90c-kLHe-M4jcMRa=_8Lhakcyrtam109WKga6XLQqmJYp0Q@mail.gmail.com>
In-Reply-To: <CAF+90c-kLHe-M4jcMRa=_8Lhakcyrtam109WKga6XLQqmJYp0Q@mail.gmail.com>
Date: Sat, 4 Sep 2021 02:41:15 +0900
Message-ID: <CABTDVhBYB1-TkxTNPCkedE0k0UBWv0eUNfmSr+KDWkpgcw12JA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000009a5e105cb1acf64"
Subject: Re: [PHP-DEV] [RFC] Random Extension 3.0
From: zeriyoshi@gmail.com (Go Kudo)

--00000000000009a5e105cb1acf64
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks nikita.

> ext/standard to ext/random. Why does it do this?

There are several reasons for this.

- The `random` extension name is already used by ext/standard and may
interfere with the build system.
- Due to the namespace rules for new extensions, it is inappropriate to
rename an extension.
- Due to history, the rand / mt_rand dependency is tricky and I thought it
was time to sort it out.
- I don't think it's a good idea to have multiple header files for a single
domain feature.
- As stated in the Future Scope, I wanted to be in a position to eliminate
module global random number state in the future.
- The existing implementation and the object implementation share most of
the same logic. It was necessary to merge them into one to make them common=
.

I certainly didn't want to require a workaround for PHP 8.2 or later for
extensions that depended on ext/standard respectively, but I decided that I
had no choice for the above reasons.

> just don't make it a requirement.

I would like to modify the design.

> I don't think it makes sense to switch these functions to use
cryptographic randomness by default...

While these may not need to be cryptographically secure, I don't think they
need to be state-dependent as well. Probably no one would look at the
function name and think that it depends on the module global state.

php_random_int() doesn't have any state anywhere (except OS) and can
generate the requested random number. I don't see any problem with these
functions using php_random_int() as a random number source.

Regards,
Go Kudo


2021=E5=B9=B49=E6=9C=884=E6=97=A5(=E5=9C=9F) 1:02 Nikita Popov <nikita.ppv@=
gmail.com>:

> On Thu, Sep 2, 2021 at 5:10 PM Go Kudo <zeriyoshi@gmail.com> wrote:
>
>> Hi Internals.
>>
>> Expanded from the previous RFC and changed it to an RFC that organizes t=
he
>> whole PHP random number generator. Also, the target version has been
>> changed to 8.2.
>>
>> https://wiki.php.net/rfc/rng_extension
>> https://github.com/php/php-src/pull/7453
>>
>> Hopefully you will get some good responses.
>>
>
> This looks pretty nice to me. A few bits of feedback:
>
>  * Unlike the previous versions of the RFC, this one also moves all of th=
e
> existing RNG-related functionality from ext/standard to ext/random. Why
> does it do this? This doesn't really seem related to the problem this RFC
> is solving.
>
>  * Regarding the abstract class Random\NumberGenerator: You currently nee=
d
> the abstract class, because php_random_ng is tied to the object. An
> alternative design that would allow Random\NumberGenerator to be an
> interface would be to make it independent of the object, such that the
> structure can be allocated in the Random constructor for userland
> implementations. Of course, internal implementations could still embed it
> as part of their objects -- just don't make it a requirement.
>
>  * The future scope mentions: "Changes random source to php_random_int() =
a
> shuffle(), str_shuffle(), and array_rand()". I don't think it makes sense
> to switch these functions to use cryptographic randomness by default...
>
> Regards,
> Nikita
>

--00000000000009a5e105cb1acf64--