On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:
Hi!
Thanks for your time reviewing the patch, appreciated.
> 1) nullable properties
I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.
I think this is an attempt to achieve more type
Hi!
> That said, how do you feel about compromising by adding this function
> in addition to the raw API?
>
> function ucsdet_detect_encoding(string $text, string $hint = null,
> bool $filter = false) {
> $det = new IntlCharsetDetector($text);
> if ($hint !== null) {
> $det->setDeclaredEn
Hi!
> The *var* keyword is not going to be deprecated and its meaning is
> currently kind of ambiguous. I tried to assign it a new meaning in
> the
Why is it ambiguous? It's pretty well defined, it's the same as public.
> class Foo {
>
> val $x;
>
> var $y;
>
> val $z;
>
> }
>
> class Bar
Hi!
> Thanks for your time reviewing the patch, appreciated.
>
> > 1) nullable properties
>
> I agree that we need a way to that, but I would rather see it
> covered by nullable types rfc.
I think this is an attempt to achieve more type safety than even fully
typed languages like Ja
Hi!
> Yes and no.
> Patch uses php_random_bytes(), so it uses appropriate PRNG for the system.
> php_random_bytes() is supposed to be available always.
True, but is it always OK to export its state to anybody who asks, on
demand, in unlimited numbers? I'm not so sure.
> Experts say secure PRNG l
Hi Stas,
On Wed, Apr 13, 2016 at 1:12 AM, Stanislav Malyshev wrote:
>
>> PRNG like /dev/urandom is supposed to be secure, but fair point. It
>> may be good idea keeping old hash based session ID just in case
>> someone find vulnerability. I suppose it's unlikely with modern PRNGs,
>> though.
>
>
I'm trying to decide just whether or not
https://bugs.php.net/bug.php?id=71927 is "working as intended" as well
as what the expected behavior in this situation /should/ be.
https://3v4l.org/HfU1g indicates that at the very least HHVM and PHP
disagree on the correct output, and testing the same sor
https://wiki.php.net/rfc/octal.overload-checking
Because having this expression evaluate to true makes me sad: ("\000"
=== "\400")
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Took me awhile to get back around to this problem, but this version feels okay.
https://github.com/php/php-src/compare/master...sgolemon:short-ternary.coalesce
It's less efficient than earlier versions, but no worse than the
current `A = A ?: B` syntax (which is effectively what it does, with
the
Hi Andrey,
On Tue, Apr 12, 2016 at 8:12 PM, Andrey Andreev wrote:
>
> On Tue, Apr 12, 2016 at 2:04 PM, Yasuo Ohgaki wrote:
>>
>> Hi Philip,
>>
>> On Tue, Apr 12, 2016 at 5:38 PM, Philip Hofstetter
>> wrote:
>> > On Tue, Apr 12, 2016 at 10:21 AM, Michael Wallner wrote:
>> >> On 08/04/16 04:17,
On Tue, Apr 12, 2016 at 2:29 PM, Anatol Belski wrote:
> Hi,
>
> Time goes by fast - no sooner 7.0 was unleashed on the world than 7.1 bangs
> at the door. I would like to bring a couple of points regarding this.
>
> There is enough time yet, but it would make full sense all the RFC authors
> tar
Hi,
Time goes by fast - no sooner 7.0 was unleashed on the world than 7.1 bangs
at the door. I would like to bring a couple of points regarding this.
There is enough time yet, but it would make full sense all the RFC authors
targeting 7.1 to finalize the work and get the RFC voted. Or the RFCs,
Hi!
> Lack of proper API for required task is our problem. Misuse is not ours. IMHO.
No, it is our problem. We can't just create whatever and throw it over
the fence. The properly designed API has to make correct use very easy
and incorrect use very hard. That's the point of designing the API, no
2016-04-12 18:36 GMT+03:00 Midori Koçak :
> what is sugar?
>
Here is a description:
https://en.wikipedia.org/wiki/Syntactic_sugar
But my proposal, almost not realistic implement, although I may be
mistaken... ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Hi!
> PRNG like /dev/urandom is supposed to be secure, but fair point. It
> may be good idea keeping old hash based session ID just in case
> someone find vulnerability. I suppose it's unlikely with modern PRNGs,
> though.
That assumes we use /dev/urandom directly and it is always available on
al
what is sugar?
On Monday, 11 April 2016, S.A.N wrote:
> Maybe even more sugar? :)
>
>
> class SugarCache
> {
> // Methode getValueFromDB() called, if its value null
> public $value ??= $this->getValueFromDB();
>
> // Methode getValueFromDB() called, if $value not transmitted or null
> value
On Tue, Apr 12, 2016 at 8:40 PM, Remi Collet wrote:
> Perhaps, no need to reinvent the wheel...
>
> There is already 2 uuid extensions
>
> - the one provided in the libuuid sources
> - the pecl one : https://pecl.php.net/package/uuid
>
> No need to create more confusion.
>
> If something missing,
On Apr 12, 2016 15:02, "Ivan Enderlin"
wrote:
>
> Hello Marco,
>
> Actually, you are trying to access to something that does not exist, so
you get a null value. This part is logical. However, yes, a notice would be
welcomed except it may be skipped for historical reasons I reckon. Probably
to work
Perhaps, no need to reinvent the wheel...
There is already 2 uuid extensions
- the one provided in the libuuid sources
- the pecl one : https://pecl.php.net/package/uuid
No need to create more confusion.
If something missing, just add it in the existing pecl ext.
If needed, open a RFC to merge
>
> I would prefer not to refer to random to avoid any confusion with the
> recent added random function. As uuid is not crypto safe and is not aimed
> to. Users will then hopefully not think about using instead of the random
> api.
>
> Also uuid alone may be a problem (bc?) It sounds like a logica
On Apr 12, 2016 7:56 PM, "Colin O'Dell" wrote:
>
> On Tue, Apr 12, 2016 at 2:09 AM Sebastian Bergmann
> wrote:
>
> > In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
> > as well as Windows's CryptGenRandom() and uses /dev/urandom as a
fallback.
> >
> > I think it would be
On 12.04.2016 at 14:59, Marco Pivetta wrote:
> I just stumbled upon behavior that seems to "fail silently" regardless of
> its very questionable validity:
>
>
> $a = 1;
>
> var_dump($a[123]); // NULL, no notice
>
> https://3v4l.org/b3rDr
>
> Are there specific reasons why no notice is thrown
Hello Marco,
Actually, you are trying to access to something that does not exist, so
you get a null value. This part is logical. However, yes, a notice would
be welcomed except it may be skipped for historical reasons I reckon.
Probably to work well with `isset` or similar scenario.
Cheers.
Hello,
I just stumbled upon behavior that seems to "fail silently" regardless of
its very questionable validity:
https://3v4l.org/b3rDr
Are there specific reasons why no notice is thrown? Is it by design? If so,
does anyone remember why?
I haven't checked if this affects other types too. I know
Results for project PHP master, build date 2016-04-12 06:35:35+03:00
commit: 60b1441
previous commit:a186ac0
revision date: 2016-04-07 10:26:32+09:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Tue, Apr 12, 2016 at 2:09 AM Sebastian Bergmann
wrote:
> In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
> as well as Windows's CryptGenRandom() and uses /dev/urandom as a fallback.
>
> I think it would be great if we added a function that wraps
> /proc/sys/kernel/rand
Hi,
On Tue, Apr 12, 2016 at 2:04 PM, Yasuo Ohgaki wrote:
> Hi Philip,
>
> On Tue, Apr 12, 2016 at 5:38 PM, Philip Hofstetter
> wrote:
> > On Tue, Apr 12, 2016 at 10:21 AM, Michael Wallner wrote:
> >> On 08/04/16 04:17, Yasuo Ohgaki wrote:
> >>
> >>> PRNG like /dev/urandom is supposed to be sec
Hi Philip,
On Tue, Apr 12, 2016 at 5:38 PM, Philip Hofstetter
wrote:
> On Tue, Apr 12, 2016 at 10:21 AM, Michael Wallner wrote:
>> On 08/04/16 04:17, Yasuo Ohgaki wrote:
>>
>>> PRNG like /dev/urandom is supposed to be secure, but fair point. It
>>> may be good idea keeping old hash based session
Hi Michael,
On Tue, Apr 12, 2016 at 5:21 PM, Michael Wallner wrote:
>> PRNG like /dev/urandom is supposed to be secure, but fair point. It
>> may be good idea keeping old hash based session ID just in case
>> someone find vulnerability. I suppose it's unlikely with modern PRNGs,
>> though.
>
> I'
Hi,
On 12/04/2016 09:59, Pierre Joye wrote:
>> Alternatively and maybe more portable, libuuid (should be part of all
>> decent systems too) could be a first choice.
>
> Forgot to mention: https://pecl.php.net/package/uuid
>
>> BSD also provides
>> compliant APIs as part of their libc
>> (https:/
Hi
On Tue, Apr 12, 2016 at 10:21 AM, Michael Wallner wrote:
> On 08/04/16 04:17, Yasuo Ohgaki wrote:
>
>> PRNG like /dev/urandom is supposed to be secure, but fair point. It
>> may be good idea keeping old hash based session ID just in case
>> someone find vulnerability. I suppose it's unlikely w
On 08/04/16 04:17, Yasuo Ohgaki wrote:
> PRNG like /dev/urandom is supposed to be secure, but fair point. It
> may be good idea keeping old hash based session ID just in case
> someone find vulnerability. I suppose it's unlikely with modern PRNGs,
> though.
I've come to think that "unlikely" is s
On Tuesday, April 12, 2016, Pierre Joye wrote:
> On Apr 12, 2016 1:09 PM, "Sebastian Bergmann" > wrote:
> >
> > In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
> > as well as Windows's CryptGenRandom() and uses /dev/urandom as a
> fallback.
> >
> > I think it would be gr
On Tue, Apr 12, 2016 at 2:52 PM, Pierre Joye wrote:
> On Apr 12, 2016 1:09 PM, "Sebastian Bergmann" wrote:
>>
>> In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
>> as well as Windows's CryptGenRandom() and uses /dev/urandom as a fallback.
>>
>> I think it would be great i
On Apr 12, 2016 1:09 PM, "Sebastian Bergmann" wrote:
>
> In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
> as well as Windows's CryptGenRandom() and uses /dev/urandom as a fallback.
>
> I think it would be great if we added a function that wraps
> /proc/sys/kernel/random/u
35 matches
Mail list logo
