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 k
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 objections here. I have been hitting annoyin
On Tue, Jun 21, 2016 at 2:28 PM, Alexander Moskalev wrote:
> 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.
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
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 al
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 without such file p
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 confus
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 create new pull-reque
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
>>
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 th
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 we
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 m
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 create new pull-request
with code and tests.
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 nu
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, the
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 opti
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 t
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
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 precompiler
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 th
20 matches
Mail list logo
