Hi Pierre,
On Tue, Jan 13, 2015 at 11:07 AM, Pierre Joye wrote:
> I am all in favor of having new RNG functions to make it easier and
> safer to use RNG with PHP.
>
Let's have it for PHP 7!
What's the status of your new crypt extension?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Jan 11, 2015 at 2:12 PM, Andrea Faulds wrote:
> Hey internals,
>
> As we’re moving to clean some things up in PHP 7, I think it might be worth
> looking at the rand()/mt_rand() situation.
>
> Currently, we have two standard-library functions to obtain a random number:
> rand() and mt_ran
On 01/12/2015 01:31 AM, Andrea Faulds wrote:
> Hi Rasmus,
>
>> On 12 Jan 2015, at 09:06, Rasmus Lerdorf wrote:
>>
>> Yes, there is plenty of code out there that relies on srand()+rand()
>> returning a repeatable sequence of pseudo-random numbers. I have written
>> some myself. C devs are very fam
I fail at reply to all.
On 12 January 2015 at 16:52, Leigh wrote:
> On 12 January 2015 at 09:31, Andrea Faulds wrote:
>> - To produce a repeatable sequence of random numbers (works, but only if you
>> and the sole user of the global random number generator, which is not
>> guaranteed by any m
Hi!
>> - To produce a repeatable sequence of random numbers (works, but
>> only if you and the sole user of the global random number
>> generator, which is not guaranteed by any means)
If you write your code it is guaranteed. Note that it's not some API
we're designing out of the blue, it is some
Hi Andrea,
On Mon, Jan 12, 2015 at 10:06 AM, Andrea Faulds wrote:
> > On 12 Jan 2015, at 00:55, Yasuo Ohgaki wrote:
> >
> > It works, but I prefer to have procedural API also (and OO API if it is
> needed.)
> > I like multi paradigm programming language.
>
> I don’t see the point of a “procedur
> On 12 Jan 2015, at 09:31, Andrea Faulds wrote:
>
> Hi Rasmus,
>
>> On 12 Jan 2015, at 09:06, Rasmus Lerdorf wrote:
>>
>> Yes, there is plenty of code out there that relies on srand()+rand()
>> returning a repeatable sequence of pseudo-random numbers. I have written
>> some myself. C devs ar
Hi Rasmus,
> On 12 Jan 2015, at 09:06, Rasmus Lerdorf wrote:
>
> Yes, there is plenty of code out there that relies on srand()+rand()
> returning a repeatable sequence of pseudo-random numbers. I have written
> some myself. C devs are very familiar with this behaviour of srand.
C devs are also
On 01/11/2015 06:05 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Also, FWIW, anyone who used the Suhosin patch couldn’t use srand()
>> because it disabled it.
>
> And? You can disable any function in PHP, that doesn't mean anything.
>
>> Because if we don’t break it, people will continue to rely on
Hi!
> Also, FWIW, anyone who used the Suhosin patch couldn’t use srand()
> because it disabled it.
And? You can disable any function in PHP, that doesn't mean anything.
> Because if we don’t break it, people will continue to rely on it, and
> this binds our hands for future versions.
Sorry, tha
Hi,
> On 12 Jan 2015, at 01:20, Stanislav Malyshev wrote:
>
>> The manual explicitly guarantees that code should not rely on the
>> random number generator being predictable.
>
> Where exactly does it say that? The only note I've found is this:
> http://php.net/manual/en/function.mt-srand.php
>
Hey,
> On 12 Jan 2015, at 01:12, Stanislav Malyshev wrote:
>
>> * Get rid of rand(), srand() and getrandmax() * Rename mt_rand(),
>> mt_srand() and mt_getrandmax() to rand(), srand(), and getrandmax()
>> but add mt_* aliases for backwards-compatibility
>
> This means rand() and mt_rand() would
Hi!
> The manual explicitly guarantees that code should not rely on the
> random number generator being predictable.
Where exactly does it say that? The only note I've found is this:
http://php.net/manual/en/function.mt-srand.php
5.2.1 The Mersenne Twister implementation in PHP now uses a new
Hi!
> * Get rid of rand(), srand() and getrandmax() * Rename mt_rand(),
> mt_srand() and mt_getrandmax() to rand(), srand(), and getrandmax()
> but add mt_* aliases for backwards-compatibility
This means rand() and mt_rand() would do the same. That however assumes
that OS's libc random-number fu
On Jan 12, 2015 8:08 AM, "Andrea Faulds" wrote:
>
> Hey Stas,
>
> > On 12 Jan 2015, at 01:03, Stanislav Malyshev
wrote:
> >
> > Having new, better API is fine. Breaking existing working code because
> > new, better API is possible, is not fine.
>
> The manual explicitly guarantees that code shoul
Hey Stas,
> On 12 Jan 2015, at 01:03, Stanislav Malyshev wrote:
>
> Having new, better API is fine. Breaking existing working code because
> new, better API is possible, is not fine.
The manual explicitly guarantees that code should not rely on the random number
generator being predictable.
I
Hi Yasuo,
> On 12 Jan 2015, at 00:55, Yasuo Ohgaki wrote:
>
> It works, but I prefer to have procedural API also (and OO API if it is
> needed.)
> I like multi paradigm programming language.
I don’t see the point of a “procedural API” here, it’d just be a set of thin
wrappers around the OOP
Hi!
> Something like this, maybe:
>
> $numgen = new RandomNumberGenerator(RAND_MERSENNE_TWISTER, time()); //
> could auto-seed with time()
> $randInt1 = $numgen->getInt(0, 100); // gets random integer and advances
> this generator
> list($randInt2, $numgen) = $numgen->newGetInt(0, 1
Hi Andrea,
On Mon, Jan 12, 2015 at 9:05 AM, Andrea Faulds wrote:
> > On 11 Jan 2015, at 23:56, Jordi Boggiano wrote:
> >
> > On 11/01/2015 22:12, Andrea Faulds wrote:
> >> * Make mt_srand() and srand() do nothing and produce a deprecation
> notice
> >
> > That is the only point with which I d
Hi all,
On Mon, Jan 12, 2015 at 7:12 AM, Andrea Faulds wrote:
> * Use a 64-bit random number generation algorithm on 64-bit platforms
> (or invoke the 32-bit generator twice)
Comment for those who does not know 64 bit version of MT rand, please read
http://www.math.sci.hiroshima-u.ac.jp/~m-
Hey Leigh,
> On 12 Jan 2015, at 00:23, Leigh wrote:
>
> On 11 January 2015 at 22:12, Andrea Faulds wrote:
>> * Get rid of rand(), srand() and getrandmax()
>> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
>> getrandmax() but add mt_* aliases for backwards-compatib
On 11 January 2015 at 22:12, Andrea Faulds wrote:
>
> * Get rid of rand(), srand() and getrandmax()
> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
> getrandmax() but add mt_* aliases for backwards-compatibility
Also, this breaks all code currently using rand() a
On 11 January 2015 at 22:12, Andrea Faulds wrote:
> * Get rid of rand(), srand() and getrandmax()
> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
> getrandmax() but add mt_* aliases for backwards-compatibility
> * Make mt_srand() and srand() do nothing and produ
Hey Yasuo and Jordi,
> On 11 Jan 2015, at 23:56, Jordi Boggiano wrote:
>
> On 11/01/2015 22:12, Andrea Faulds wrote:
>> * Make mt_srand() and srand() do nothing and produce a deprecation notice
>
> That is the only point with which I disagree. Looking at
> http://3v4l.org/FLHBV we see that w
Hi Andrea,
On Mon, Jan 12, 2015 at 7:12 AM, Andrea Faulds wrote:
> * Get rid of rand(), srand() and getrandmax()
> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(),
> and getrandmax() but add mt_* aliases for backwards-compatibility
> * Make mt_srand() and srand() do n
Overall it's a good plan IMO and it would clean things up for sure. On
the other hand if we don't remove old docs it will just make the docs
pages even more complex since the docs for rand() will highly depend on
which PHP version is used.
On 11/01/2015 22:12, Andrea Faulds wrote:
* Make m
Hey Stelian,
> On 11 Jan 2015, at 22:43, Stelian Mocanita wrote:
>
> All this sounds really good, and I am all for uniformity when the downsides
> are not too much to handle. I would have one suggestion though, and that
> would be to add deprecation notices on every "mt_" alias so in time they
All this sounds really good, and I am all for uniformity when the downsides
are not too much to handle. I would have one suggestion though, and that
would be to add deprecation notices on every "mt_" alias so in time they
can be safely removed and cleaning everything up.
On Sun, Jan 11, 2015 at 11
> De : Andrea Faulds [mailto:a...@ajf.me]
>
> Would that sound good?
That sounds very good to me :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
29 matches
Mail list logo
