-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 26/11/2015 18:24, Nikita Popov a écrit :
> Here is an implementation of this mechanism for PHP:
> https://github.com/php/php-src/pull/1565
>
> This is the approach I would recommend for PHP. The patch for this
> change is small and non-intrusive
Hello!
The PHP development team announces the immediate availability of PHP
5.6.16. Several
bugs have been fixed. All PHP 5.6 users are encouraged to upgrade to this
version.
For source downloads of PHP 5.6.16 please visit our downloads page:
http://www.php.net/downloads.php
Windows binaries ca
>
> 3. (Fatal error on many collisions). While the two previous options try to
> ensure that hashtables stay efficient regardless of the used keys, the last
> option aims to simply detect malicious array keys and abort the script in
> such a case.
>
> This is done by counting the number of collisio
Hi internals!
This mail turned out to be rather long, so I'll start with a TL;DR:
To fix the HashDos vulnerability for *all* cases (rather than just GET/POST
parsing), I propose to introduce collision counting during hashtable
insertion operations. This will throw a fatal error if the number of
c
Answers inline
On Thu, Nov 26, 2015 at 11:58 AM, Chris Riley wrote:
>
> On 26 November 2015 at 16:05, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Ok then. I'll pretend that lack of interest didn't happen many other
>> situations (like http://marc.info/?t=14460876781)
Levi, I was asking about the reasons it was rejected. While researching, I
found the original RFC was voted with 123 votes (71% approval), and yet was
marked as 'declined'. I didn't know why, couldn't find why, so I figured
I'd ask (as it strikes me as a major feature that's missing).
2015-11-26 1
On Thu, Nov 26, 2015 at 9:57 AM, Rowan Collins wrote:
> guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
>>
>> Ok then. I'll pretend that lack of interest didn't happen many other
>> situations (like http://marc.info/?t=14460876781) and move on.
>
>
> It's possible that a lot of the core d
guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
Ok then. I'll pretend that lack of interest didn't happen many other
situations (like http://marc.info/?t=14460876781) and move on.
It's possible that a lot of the core devs are still concentrating on
getting the changes in 7.0 bedded in
On 26 November 2015 at 16:05, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Ok then. I'll pretend that lack of interest didn't happen many other
> situations (like http://marc.info/?t=14460876781) and move on.
>
> I don't want to bring the patch up to date/simplify it without
Ok then. I'll pretend that lack of interest didn't happen many other
situations (like http://marc.info/?t=14460876781) and move on.
I don't want to bring the patch up to date/simplify it without a clear
decision of at least be willing to discuss the patch and not reject by all
means.
I'd propo
Hey, Rowan, don't apologize for making the case for what you believed to be
the right way. I'm glad I could summarize my views in a way that you could
agree with me.
I've reread your point about the transpilers and obfuscators, and you're
right, I misunderstood what you said. I'm sorry.
Now, I'd
guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
I haven't seen any user asking for traits
Just because you didn't see it, doesn't mean it didn't happen.
I just did a very quick search on Google for php + mixins, limited to
2007 or earlier (long before the current Trait implementation was
Let's be clear. I haven't seen any user asking for traits, which introduced
almost the same amount of performance cost and complexity to ZE. It was
proposed by a "long term contributor" and everybody said yay.
When multiple userland people ask about the same feature, every single
major framework u
Hi Pedro,
I agree with most of the points in your last mail. At the end of the
day, the reasons are fairly subjective, and relate to how the feature
will be perceived, and the freedom to design it without annoying people,
but that doesn't stop them being real.
However I would like to come ba
> Ah, and please stop saying "it should be in docblock". This argument is
> just bull... to suppress the actual people interested to see this natively
> available and just exposes your lack of interest into language improvement.
Every feature has a cost and benefit. It is perfectly fine to have th
Hi,
The eighth release candidate for 7.0.0 was just released and can be
downloaded from:
https://downloads.php.net/~ab/
The Windows binaries are available at
http://windows.php.net/qa/
This release contains fixes for yet 11 reported bugs. Given no major issue
were discovered in between
Results for project PHP master, build date 2015-11-26 09:26:27+02:00
commit: f9dd83cbe37bcbae173fb3e08b62cfc1c2718085
revision date: 2015-11-26 12:00:37+08:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
mem
Hi, Rowan. I'll respond to some points that have become recurrent.
1) It's might not be objectively bad to add this feature in docblocks, but
it will be objectively wrong to keep calling them "DocBlocks" if they are
no longer documentation-only blocks.
2) Even though PHP already treats docblocks
guilhermebla...@gmail.com wrote on 26/11/2015 01:13:
Ok, so I'll explain why it's not "the same way" as you imagine.
I've heard this many times already so I'll save you keystrokes.
- "Sure, we can do that on docblocks"
- "Based on that, it doesn't need to be part of core and can safely be
imple
19 matches
Mail list logo
