Re: [PHP-DEV] [RFC] RNG fixes

Le mercredi 15 juin 2016, 21:43:05 Fleshgrinder a écrit : > But let use stop that now. I already wrote that someone should come up > with use cases for predictable random numbers other than creating > insecure secrets. This is the main problem that needs solving, people > using this stuff without

[PHP-DEV] Re: Enable Zend Signals by Default

Hey: On Tue, Jun 21, 2016 at 9:02 AM, Rasmus Lerdorf wrote: > On Mon, Jun 20, 2016 at 1:25 PM, Dmitry Stogov wrote: > > So, I propose to switch zend-signals on, and revert back if it makes > problems to 7.1 release process. > Any objections? > > > No

[PHP-DEV] Wiki edit request

Hello PHP Team, I have spotted a few minor typographical edits in the wiki I'd like to correct, specifically one in the "PHP RFC: Void Return Type" document. Would you please grant my wiki user edit access so I can submit the correction? Username: pixelchutes Kind regards, - Mike

Re: [PHP-DEV] [RFC] RNG fixes

Hi, I already wrote this message once, but it seems to have evaporated into the ether. So apologies if it reappears and this is revealed as a poor duplicate of it! On 21/06/2016 18:37, Fleshgrinder wrote: I don't understand the drive to holding on to obviously faulty stuff. Nikic proposed

Re: [PHP-DEV] Re: Send files in CURL from string

Thank you! 2016-06-21 23:31 GMT+03:00 Davey Shafik : > you can use a memory stream I thought about something like that. But if we created memory stream (php://memory ?), we have file pointer resource related to this stream. And we cannot read or write something in this stream

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > I am sorry, what this link is supposed to illustrate? That if one > doesn't read the docs and uses mt_rand wrong they'd get exactly what it > is supposed to do? Ok, true, and? > > This is an obviously false statement, so obviously that I am

Re: [PHP-DEV] Re: Send files in CURL from string

On Tue, Jun 21, 2016 at 11:38 AM, Alexander Moskalev wrote: > Sorry for annoying mail, but it's really small and simple feature, which > can be implemented by few lines of curl options. But with API realisation > questions. > Please, help me to choose correct way, and I will

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > https://news.ycombinator.com/item?id=9941364 I am sorry, what this link is supposed to illustrate? That if one doesn't read the docs and uses mt_rand wrong they'd get exactly what it is supposed to do? Ok, true, and? >> The PHP approach seems to be that any crazy behavior is acceptable >>

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 9:23 PM, Lester Caine wrote: > Can someone explain why I should need 'crypto safe' random numbers when > ALL *I* use rand for is to give a random order to content items on the > page. Something more in sync with the shuffle and array_rand without the > need to recode to actually use

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > What is for you "obviously faulty stuff" for literally thousands of > people is "code that works". I appreciate that there's a number of new > hip randomness tests that mt_rand may not satisfy, and there's new and > exciting number generator that

Re: [PHP-DEV] [RFC] RNG fixes

On 21/06/16 19:32, Stanislav Malyshev wrote: >> I don't understand the drive to holding on to obviously faulty stuff. > What is for you "obviously faulty stuff" for literally thousands of > people is "code that works". I appreciate that there's a number of new > hip randomness tests that mt_rand

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > I don't understand the drive to holding on to obviously faulty stuff. What is for you "obviously faulty stuff" for literally thousands of people is "code that works". I appreciate that there's a number of new hip randomness tests that mt_rand may not satisfy, and there's new and exciting

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 7:33 AM, Stanislav Malyshev wrote: >> Mcrypt is meant to be replaced anyways and OpenSSL might be too if we >> can come up with a nicer implementation that actually hides the >> underlying library (e.g. sodium). > > This is another problem. So we have OpenSSL, then we have mcrypt,

Re: [PHP-DEV] [RFC] RNG fixes

On 6/19/2016 11:18 PM, Tom Worster wrote: > Actually I satisfied myself that both MT19937 and PHP's mt_rand() produce > good quality random variates and I posted the evidence behind the belief. > I don't think being slow and inefficient with memory justifies removal or > deprecation (premature

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 11:41 AM, Jordi Boggiano wrote: > On 21/06/2016 06:33, Stanislav Malyshev wrote: >> Hi! >> >>> Why do we need so many functions to get a random int anyways if we now >>> have random_int()? I would like to see all of them deprecated and >>> removed in PHP 8.0. >> >> I don't understand

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-06-21

Results for project PHP master, build date 2016-06-21 06:29:44+03:00 commit: 8953308 previous commit:459965b revision date: 2016-06-20 22:41:36+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Statically verifiable callables

Morning internals, I would like to gather some reactions on the proposal to add a 'statically verifiable callable as a closure language construct'. That would be functionally similar to the recently added Closure::fromCallable() with the exception being statically verified by IDEs or

Re: [PHP-DEV] [RFC] RNG fixes

On 21/06/2016 06:33, Stanislav Malyshev wrote: Hi! Why do we need so many functions to get a random int anyways if we now have random_int()? I would like to see all of them deprecated and removed in PHP 8.0. I don't understand this drive to remove functions and break existing code. What is