On Sep 22, 2016 1:07 AM, "Levi Morrison" wrote:
>
> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
> wrote:
> >> To handle this in code written around current __toString seems pretty
> > simple
> >
> > Yes it is, but that's not what we're talking about:
> > BC is about having perfectly fine cod
Hi!
> As linked in my first reply, there was a previous discussion on the
> topic: http://markmail.org/message/ttbgcvdu4f7uymfb
> The collision-counting approach that Yasuo references is linked at the
> start of the first mail: https://github.com/php/php-src/pull/1565
>
> Collisions are counted d
Hi Stas,
On Thu, Sep 22, 2016 at 7:47 AM, Stanislav Malyshev wrote:
>> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev
>> wrote:
>>>
I think we are better to limit max collisions.
I'm +1 for Nikita's proposal does this.
>>>
>>> Max collision per what? How much would be the limit?
On Thu, Sep 22, 2016 at 1:07 AM, Stanislav Malyshev
wrote:
> Hi!
>
> >> Lets [try] to quantify the probability of reaching the collision limit C
> > with a hashtable of size N and assuming a random hash distribution. The
> > upper bound for this should be (N choose C) * (1/N)^(C-1), with
> (1/N)^
Hi!
> I'm not so sure of this now - unless, again, I misunderstand what we're
> counting.
It just occurred to me that I possibly do misunderstand what is counted
- if the proposal is to count collisions per lookup.
I rerun my scripts with that assumption and turns out the longest
collision chain
Hi!
>> Lets [try] to quantify the probability of reaching the collision limit C
> with a hashtable of size N and assuming a random hash distribution. The
> upper bound for this should be (N choose C) * (1/N)^(C-1), with (1/N)^(C-1)
> being the probability that C elements hash to one value and (N o
Hi!
> Hi Stas,
>
> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev
> wrote:
>>
>>> I think we are better to limit max collisions.
>>> I'm +1 for Nikita's proposal does this.
>>
>> Max collision per what? How much would be the limit?
>
> Collision by keys.
Not sure I understand. What would
Hi Kiklas,
On Wed, Sep 21, 2016 at 5:06 PM, Niklas Keller wrote:
> 2016-09-21 8:54 GMT+02:00 Yasuo Ohgaki :
>>
>> Hi Stas,
>>
>> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev
>> wrote:
>> >
>> >> I think we are better to limit max collisions.
>> >> I'm +1 for Nikita's proposal does this.
On Wed, Sep 21, 2016 at 9:46 PM, Nikita Popov wrote:
> Here's a PR for the revert-to-7.0 + deprecate variant, in case we wish to
> adopt it: https://github.com/php/php-src/pull/2137
>
Pretty much the most sensible solution to all this, from my point of view.
Avoiding overloading a string with mo
On Wed, Sep 21, 2016 at 8:47 PM, Nicolas Grekas
wrote:
> > > See https://github.com/php/php-src/pull/2136
> >
> > On a technical note this is a potentially breaking change for C
> > extensions. Since it is a currently a `zend_bool` its value is
> > truthy/falsy; you are now applying specific mean
On Wed, Sep 21, 2016 at 7:51 PM, Ryan Pallas wrote:
>
>
> On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka wrote:
>
>> Hi,
>>
>> On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote:
>>
>>> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
>>> wrote:
>>> >> To handle this in code written around
On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote:
>
>> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
>> wrote:
>> >> To handle this in code written around current __toString seems pretty
>> > simple
>> >
>> > Yes it is, but
On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote:
>>
>> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
>> wrote:
>> >> To handle this in code written around current __toString seems pretty
>> > simple
>> >
>> > Yes it is, but
> > See https://github.com/php/php-src/pull/2136
>
> On a technical note this is a potentially breaking change for C
> extensions. Since it is a currently a `zend_bool` its value is
> truthy/falsy; you are now applying specific meaning to values.
>
> Maybe someone else will have more insight into w
Hi,
On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote:
> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
> wrote:
> >> To handle this in code written around current __toString seems pretty
> > simple
> >
> > Yes it is, but that's not what we're talking about:
> > BC is about having perfectl
On Wed, Sep 21, 2016 at 2:55 AM, Nicolas Grekas
wrote:
> Hello,
>
> our turn to be hit by this 7.1 BC break in Symfony:
> `ReflectionType::__toString()` now adds a `?` in front of type hints where
> `null` is allowed by their default values.
>
> But since `zend_bool` is really an `unsigned char`,
It's a point release, it's not really "up for decision" whether BC can be
broken or not on functionality that is working as intended (unless I
misunderstand the release process).
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Wed, Sep 21, 2016 at 8:07 PM, Levi Morrison
On Wed, Sep 21, 2016 at 12:07 PM, Levi Morrison wrote:
> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
> wrote:
>>> To handle this in code written around current __toString seems pretty
>> simple
>>
>> Yes it is, but that's not what we're talking about:
>> BC is about having perfectly fine cod
On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
wrote:
>> To handle this in code written around current __toString seems pretty
> simple
>
> Yes it is, but that's not what we're talking about:
> BC is about having perfectly fine code working in e.g. 7.0 be still working
> fine on 7.1 *without any
> To handle this in code written around current __toString seems pretty
simple
Yes it is, but that's not what we're talking about:
BC is about having perfectly fine code working in e.g. 7.0 be still working
fine on 7.1 *without any change*.
Right now, we have red test suites on php7.1rc2.
This is
On Wed, Sep 21, 2016 at 10:13 AM, Nicolas Grekas
wrote:
> >
> > See https://github.com/php/php-src/pull/2136
> >>
> >
> > I don't like this.
> >
>
> I understand, really. I do have to deal with BC on Symfony side also and
> it's a really hard constraint. Yet, we stick to it as much as possible, i
On Wed, Sep 21, 2016 at 10:34 AM, Nicolas Grekas
wrote:
>
>
>> I'm not so sure its a BC though. Technically nullable types don't exist
>> in 7.0 and as such would be impossible to return said question mark. Its
>> only adding support for a new feature, not changing how an existing feature
>> work
Hi Richard,
On 21.09.2016 19:39, Fleshgrinder wrote:
On 9/21/2016 8:42 AM, Andrey Hristov wrote:
Hi Richard,
On 20.09.2016 21:02, Fleshgrinder wrote:
Hi Andrey!
I am writing you because you are the last person with actual commits in
the mysqlnd extension. I would like to ask if you could hav
>
> I'm not so sure its a BC though. Technically nullable types don't exist in
> 7.0 and as such would be impossible to return said question mark. Its only
> adding support for a new feature, not changing how an existing feature
> works IMO. If nullable types had been in 7.0 its highly probably, th
On Wed, Sep 21, 2016 at 6:13 PM, Nicolas Grekas
wrote:
>
>
>> See https://github.com/php/php-src/pull/2136
>>>
>>
>> I don't like this.
>>
>
> I understand, really. I do have to deal with BC on Symfony side also and
> it's a really hard constraint. Yet, we stick to it as much as possible, in
> or
>
> See https://github.com/php/php-src/pull/2136
>>
>
> I don't like this.
>
I understand, really. I do have to deal with BC on Symfony side also and
it's a really hard constraint. Yet, we stick to it as much as possible, in
order to not add pain to others.
Sometime, we have to be pragmatic and ac
On Wed, Sep 21, 2016 at 4:49 PM, Glenn Eggleton wrote:
> This might be a bit off topic
>
> Given that you can set POST_REQUEST_SIZE in a production PHP application,
> how likely is it really that an app will encounter a HashDos attack?
>
> From what I gather this will require MBs to GBs of da
This might be a bit off topic
Given that you can set POST_REQUEST_SIZE in a production PHP application,
how likely is it really that an app will encounter a HashDos attack?
>From what I gather this will require MBs to GBs of data in order to cause a
DoS.
>From the web side, I think there are
How big of a deal will this be come 7.2? or 8.0?
A few projects will break on 7.1 regardless of whether the question
mark is prepended or not, as has already been discussed in previous
threads. The key is as Nikita has pointed out that if we don't prepend
it this method is basically useless and mu
On Wed, Sep 21, 2016 at 4:05 PM, Tom Worster wrote:
> On 9/21/16 8:37 AM, Rowan Collins wrote:
>
>> On 21 September 2016 13:02:20 BST, Glenn Eggleton
>> wrote:
>>
>>> What if we had some sort of configuration limit on collision length?
>>>
>>
>> Previous discussions have come to the conclusion t
On 9/21/16 8:37 AM, Rowan Collins wrote:
On 21 September 2016 13:02:20 BST, Glenn Eggleton wrote:
What if we had some sort of configuration limit on collision length?
Previous discussions have come to the conclusion that the difference between
normal collision frequency and sufficient for a
On Wed, Sep 21, 2016 at 3:22 PM, Niklas Keller wrote:
> 2016-09-21 14:37 GMT+02:00 Rowan Collins :
>
> > On 21 September 2016 13:02:20 BST, Glenn Eggleton
> > wrote:
> > >What if we had some sort of configuration limit on collision length?
> >
> > Previous discussions have come to the conclusion
On 9/20/16 10:25 PM, Stanislav Malyshev wrote:
Note that to avoid problems with opcache we can only randomize on
initial boot (even then synchronizing among different processes sharing
opcache may be challenging). That means that the process would be
running for extended time (at least days, in t
On Wed, Sep 21, 2016 at 3:14 PM, Nikita Popov wrote:
> On Wed, Sep 21, 2016 at 10:55 AM, Nicolas Grekas
> wrote:
>
>> Hello,
>>
>> our turn to be hit by this 7.1 BC break in Symfony:
>> `ReflectionType::__toString()` now adds a `?` in front of type hints where
>> `null` is allowed by their defaul
That still means that code designed for 7.0 will break while reflecting 7.0
code (`= null` scenario) when run on 7.1, effectively preventing upgrade,
Niklas.
On 21 Sep 2016 15:27, "Niklas Keller" wrote:
> 2016-09-21 15:14 GMT+02:00 Nikita Popov :
>
> > On Wed, Sep 21, 2016 at 10:55 AM, Nicolas G
2016-09-21 15:14 GMT+02:00 Nikita Popov :
> On Wed, Sep 21, 2016 at 10:55 AM, Nicolas Grekas >
> wrote:
>
> > Hello,
> >
> > our turn to be hit by this 7.1 BC break in Symfony:
> > `ReflectionType::__toString()` now adds a `?` in front of type hints
> where
> > `null` is allowed by their default
Am 21.09.16 um 14:49 schrieb Vesa Kaihlavirta:
On Tue, 20 Sep 2016 at 02:20 Dan Ackroyd wrote:
Hi Vesa,
On 19 September 2016 at 14:04, Vesa Kaihlavirta
wrote:
My idea is to add a strict_comparisons declaration that you can add at
the
beginning of a file in the same way as strict_types.
P
2016-09-21 14:37 GMT+02:00 Rowan Collins :
> On 21 September 2016 13:02:20 BST, Glenn Eggleton
> wrote:
> >What if we had some sort of configuration limit on collision length?
>
> Previous discussions have come to the conclusion that the difference
> between normal collision frequency and suffici
On Wed, Sep 21, 2016 at 10:55 AM, Nicolas Grekas
wrote:
> Hello,
>
> our turn to be hit by this 7.1 BC break in Symfony:
> `ReflectionType::__toString()` now adds a `?` in front of type hints where
> `null` is allowed by their default values.
>
> But since `zend_bool` is really an `unsigned char`
On Tue, 20 Sep 2016 at 02:20 Dan Ackroyd wrote:
> Hi Vesa,
>
> On 19 September 2016 at 14:04, Vesa Kaihlavirta
> wrote:
> >
> > My idea is to add a strict_comparisons declaration that you can add at
> the
> > beginning of a file in the same way as strict_types.
> >
> > Please take a look and let
On 21 September 2016 13:02:20 BST, Glenn Eggleton wrote:
>What if we had some sort of configuration limit on collision length?
Previous discussions have come to the conclusion that the difference between
normal collision frequency and sufficient for a DoS is so large that the only
meaningful se
Results for project PHP master, build date 2016-09-21 06:25:36+03:00
commit: ea52b84
previous commit:dc59aaf
revision date: 2016-09-20 12:18:55+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hello,
What if we had some sort of configuration limit on collision length?
Would give most of us a viable way to prevent our apps from being attacked,
and yet in the use cases where we require a higher limit we retain the
ability to up the limit or disable it completely.
Regards, Glenn
On Wed,
> Curious: Why do you depend on the string representation?
__toString is the only public interface on ReflectionType that allows
getting the type name, so people already build things on top.
See http://php.net/ReflectionType
Hi,
On Wed, 2016-09-21 at 10:55 +0200, Nicolas Grekas wrote:
> our turn to be hit by this 7.1 BC break in Symfony:
> `ReflectionType::__toString()` now adds a `?` in front of type hints where
> `null` is allowed by their default values.
Curious: Why do you depend on the string representation? Wha
Hello,
our turn to be hit by this 7.1 BC break in Symfony:
`ReflectionType::__toString()` now adds a `?` in front of type hints where
`null` is allowed by their default values.
But since `zend_bool` is really an `unsigned char`, we have plenty of room
to store and forward this semantic subtlety (
2016-09-21 8:54 GMT+02:00 Yasuo Ohgaki :
> Hi Stas,
>
> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev
> wrote:
> >
> >> I think we are better to limit max collisions.
> >> I'm +1 for Nikita's proposal does this.
> >
> > Max collision per what? How much would be the limit?
>
> Collision by
47 matches
Mail list logo
