Hi Niklas,
On Tue, Oct 18, 2016 at 3:36 PM, Niklas Keller wrote:
> Yasuo Ohgaki schrieb am Di., 18. Okt. 2016, 02:21:
>>
>> Hi all,
>>
>> I committed this patch that simply use php_random_bytes() w/o any BC.
>
>
> Doesn't this throw now in some environments where /dev/urandom isn't
> readable?
On Mon, Oct 17, 2016 at 11:41 PM, Sebastian Bergmann wrote:
> Am 18.10.2016 um 08:23 schrieb Sara Golemon:
>> I'm mostly curious about thoughts on API decisions.
>
> * public static function createFromBinary(string $number): BigNum;
> * public static function createFromInteger(int $number): BigNum
Am 18.10.2016 um 08:23 schrieb Sara Golemon:
> I'm mostly curious about thoughts on API decisions.
Can we make the constructor non-public and instead only have named
constructors?
* public static function createFromBinary(string $number): BigNum;
* public static function createFromInteger(int $nu
Yasuo Ohgaki schrieb am Di., 18. Okt. 2016, 02:21:
> Hi all,
>
> I committed this patch that simply use php_random_bytes() w/o any BC.
>
Doesn't this throw now in some environments where /dev/urandom isn't
readable?
Regards, Niklas
http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d87
> Looks ok to me. Would probably not hurt also add tests for various error
> conditions.
>
There's one TypeError test in there, but I can easily add more. (And
probably will on my flight tomorrow.)
> I realise this is only exposing functionality already available with
> OpenSSL but is it worth add
Hi!
> As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
>
> https://wiki.php.net/rfc/openssl.bignum
Looks ok to me. Would probably not hurt also add tests for various error
conditions.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing Li
I realise this is only exposing functionality already available with
OpenSSL but is it worth adding tests that cover some arbitrary precision
arithmetic? The tests at the moment cover integers that PHP already
handles natively without requiring either GMP or BCMath.
There's usage of zend_parse_par
As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
https://wiki.php.net/rfc/openssl.bignum
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
I committed this patch that simply use php_random_bytes() w/o any BC.
http://git.php.net/?p=php-src.git;a=commitdiff;h=48f1a17886d874dc90867c669481804de90509e8
I thought there is php_random_int(), but it's not.
So this is one of the best patch for this purpose.
There is bug reports that
On 17 October 2016 at 21:57, Nikita Popov wrote:
>
>
> I'm not sure I understand the motivation for throwing a deprecation notice
> instead of a warning. In particular, what is the action that will be taken
> here in the next major version? I guess we would throw a warning and return
> false (inst
On Mon, Oct 17, 2016 at 10:50 PM, Craig Duncan wrote:
> I've updated the RFC now to include count(null) which resolves the final
> open question.
>
> If there isn't any more feedback I'll open voting in a few days
>
> https://wiki.php.net/rfc/counting_non_countables
>
> Thanks,
> Craig
>
I'm not
I've updated the RFC now to include count(null) which resolves the final
open question.
If there isn't any more feedback I'll open voting in a few days
https://wiki.php.net/rfc/counting_non_countables
Thanks,
Craig
Hi,
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, October 17, 2016 8:08 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Regression between RC1 and RC2?
>
> Hi Stas,
>
> Stanislav Malyshev wrote:
> > Hi!
> >
> >>> So the problem basically is tha
Hi,
I've created an RFC to make it easier to work with emulated prepared
statements:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
Based on feedback from a previous thread[1], I added some context and added
two other potential solutions to the problem. Please share your feed
Hi Stas,
Stanislav Malyshev wrote:
Hi!
So the problem basically is that in PHP 7.0 both print_r and var_dump directly
print to output. This means that by the time the exception is thrown, we've
already written output. This makes it unclear how exactly the exception should
be handled. Is it oka
Hi again,
I rewrote the manual entries on utf8_encode() and utf8_decode() to be
more helpful:
http://svn.php.net/viewvc?view=revision&revision=340506
And they have now been moved to ext/standard in master:
https://github.com/php/php-src/pull/2160
I hope this settles this issue mostly.
Than
Results for project PHP master, build date 2016-10-17 06:24:55+03:00
commit: abd2c04
previous commit:77584e9
revision date: 2016-10-17 12:42:44+11:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Morning Ferenc,
I would love lxr back, Adam has a setup in the mean time, but I'm sure
he would not like everyone using it.
More words of encouragement here ...
Cheers
Joe
On Sat, Oct 15, 2016 at 3:49 PM, Ferenc Kovacs wrote:
> On Sat, Oct 15, 2016 at 12:36 PM, Christoph M. Becker
>
Hi Davey,
On Sun, Oct 16, 2016 at 6:08 PM, Yasuo Ohgaki wrote:
>
> I was planning to fix session_start() behaviors by PHP 7.1, but I
> forgot to do this completely. Partial fix is merged currently.
>
> Following PR makes session_start() return FALSE when it cannot start
> session always.
>
> http
19 matches
Mail list logo
