Hi all,
hash_hkdf() does not have sane/optimal/consistent signature, but this is
what we've decided by RFC vote. We should have good manual
page for users to avoid vulnerable usage at least.
Current hash_hkdf() manual page.
http://php.net/hash_hkdf
This is final proposal patch for
On Fri, May 12, 2017 at 8:37 PM, Dan Ackroyd wrote:
> This conversation appears to have reached an end.
>
Indeed.
No example usage that justifies current signature.
It proves what was wrong. I'll post final doc patch in new thread.
Regards,
--
Yasuo Ohgaki
Results for project PHP master, build date 2017-06-06 19:23:50-07:00
commit: 5f05527
previous commit:a867d74
revision date: 2017-06-06 12:45:20-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Am 07.06.2017 um 16:23 schrieb Pedro Magalhães:
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
wrote:
you can't simply pass something that *incidentally* changes a
pre-established rule
Hi Rowan,
Would you consider that that is not the case for your own RFC?
Thanks for creating a pull request for this!
== Original ==
From: Fleshgrinder
To: php-internals , ben.co...@zeyos.com, Dmitry Stogov
Date: Wed, 07 Jun 2017 21:29:56 +0200
Subject: Re: [PHP-DEV] Basic string
On Wed, Jun 7, 2017 at 10:03 PM, Rasmus Schultz wrote:
> What do you think about adding another option to preg_match() to allow the
> $offset parameter to be treated as the start anchor?
>
> The manual proposes to do this:
>
> $subject = "abcdef";
> $pattern =
On 07/06/2017 21:03, Rasmus Schultz wrote:
What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?
The manual proposes to do this:
$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?
The manual proposes to do this:
$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($pattern, substr($subject, $offset), $matches);
In
> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable
compromise.
I have to second that.
I might even propose to shorten it from "fn" to just "f" - the resulting
syntax then resembles a mathematical predicate :-)
On Wed, Jun 7, 2017 at 5:20 PM, Stephen Reay
On 6/7/2017 7:15 PM, Benjamin Coutu wrote:
> Hi Dmitry,
>
> I just noticed that all basic string comparison functions in
> Zend/zend_builtin_functions.c, especially "strcmp", "strncmp",
> "strcasecmp", "strncasecmp" still use the old and inefficient
> parameter parsing API, unlike similar
On 6/7/2017 8:23 PM, Pedro Magalhães wrote:
> I will not change the target version now during the voting phase. Also
> because it wouldn't make sense to vote for a feature for 8.0 yet. If the
> RFC is rejected and the sentiment is that most people would agree with the
> change but not with the
On Wed, Jun 7, 2017 at 2:41 PM, François Laupretre
wrote:
>
> So, I respectfully ask you to change target to PHP 8 or explain why we
> should make an exception to the process. Reasons you gave so far are OK for
> a major version, but not for a minor one. This is not against
On 7 June 2017 17:36:01 BST, "Pedro Magalhães" wrote:
>On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins
>wrote:
>
>> On 7 June 2017 15:23:13 BST, "Pedro Magalhães"
>wrote:
>> >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
Hi Dmitry,
I just noticed that all basic string comparison functions in
Zend/zend_builtin_functions.c, especially "strcmp", "strncmp", "strcasecmp",
"strncasecmp" still use the old and inefficient parameter parsing API, unlike
similar functions in ext/standard/string.c such as
On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins
wrote:
> On 7 June 2017 15:23:13 BST, "Pedro Magalhães" wrote:
> >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
> >wrote:
> >
> >> you can't simply pass something that
On 7 June 2017 15:23:13 BST, "Pedro Magalhães" wrote:
>On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
>wrote:
>
>> you can't simply pass something that *incidentally* changes a
>> pre-established rule
>
>
>Hi Rowan,
>
>Would you consider that that is not
> On 7 Jun 2017, at 20:37, Björn Larsson wrote:
>
> Well, one reason to use fn or even lambda was to signal that this is
> different then a regular function.
>
> When it comes to number of keystrokes I guess that some inspiration
> has been taken from other languages
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
wrote:
> you can't simply pass something that *incidentally* changes a
> pre-established rule
Hi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-strings
> On Jun 7, 2017, at 6:31 AM, Derick Rethans wrote:
>
> I voted no because of the BC break.
>
Changed my vote to no for the same reason. The subtly of the BC would make bugs
potentially difficult to discern. Would happily vote yes again for an RFC
targeting 8.
Aaron
On 07.06.2017 at 15:32, Dan Ackroyd wrote:
> On 7 June 2017 at 13:41, François Laupretre wrote:
>
>> Right. Introducing this change is not compatible with the release process,
>> whatever the result of the vote... explain why we
>> should make an exception to the process.
>
On 7 June 2017 14:32:50 BST, Dan Ackroyd wrote:
>The RFC process is the way that we change the rules, and RFCs are not
>constrained by any previous RFC or by any 'constitution' as PHP
>doesn't have one. This is similar to how the UK parliament isn't
>constrained by any
Hi Francois,
I'm in favour of shipping PHP code as part of either PHP core, and for
extensions.
I would use this for Imagick. There are several 'helper' functions
that would make this library easier to use, that are trivial to write
in PHP, that are incredibly not trivial to write in C.
>
Den 2017-06-06 kl. 06:38, skrev Stephen Reay:
On 6 Jun 2017, at 03:18, Björn Larsson wrote:
Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
On 6/5/2017 9:03 PM, Ryan Pallas wrote:
However,
Am 07.06.2017 um 13:31 schrieb Derick Rethans:
> I voted no because of the BC break.
Same.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 7 June 2017 at 13:41, François Laupretre wrote:
> Hi,
>
> Right. Introducing this change is not compatible with the release process,
> whatever the result of the vote... explain why we
> should make an exception to the process.
The RFC process is the way that we change
On 06/04/17 at 08:02pm, Jakub Zelenka wrote:
> On Sun, Jun 4, 2017 at 7:22 PM, Jelle van der Waa wrote:
>
> > On 06/04/17 at 07:00pm, Jakub Zelenka wrote:
> > > On Wed, May 31, 2017 at 11:19 AM, Jelle van der Waa
> > wrote:
> > >
> > > > I would like to propose
Hi,
Right. Introducing this change is not compatible with the release
process, whatever the result of the vote.
So, I respectfully ask you to change target to PHP 8 or explain why we
should make an exception to the process. Reasons you gave so far are OK
for a major version, but not for a
Bump on this thread because I would like to hear some feedback.
Thanks!
> On Mar 31, 2017, at 10:55 PM, Andrew Nester wrote:
>
>
> Hello everyone!
>
> I’ve been working on fix for following bug:
> https://bugs.php.net/bug.php?id=74063
Voting "no" as well, since applications relying on "array_keys()" and
assuming on the allowed integer range of those may even become vulnerable.
This is one of those subtle BC breaks that are extremely hard to find.
On 7 Jun 2017 2:12 p.m., "François Laupretre" wrote:
>
On 06.06.2017 at 19:55, Pedro Magalhães wrote:
> Hi all,
>
> I have just opened the vote on this RFC.
>
> The main goal of the RFC is to eliminate the inconsistency in arrays when
> negative numeric keys are used explicitly and the following implicit keys
> will start from zero.
>
> You can
Hi,
The same for me. Strange to see 7 people willing to introduce such a BC
break in a minor version, or did I miss something ?
Anyway, +1 to introduce the change in PHP 8.
Cheers,
François
Le 07/06/2017 à 13:31, Derick Rethans a écrit :
On Tue, 6 Jun 2017, Pedro Magalhães wrote:
Hi all,
On Tue, 6 Jun 2017, Pedro Magalhães wrote:
> Hi all,
>
> I have just opened the vote on this RFC.
>
> The main goal of the RFC is to eliminate the inconsistency in arrays when
> negative numeric keys are used explicitly and the following implicit keys
> will start from zero.
>
> You can find
Hi,
thanks to all for taking the time to think about it and give your opinion.
It seems that we may gather a consensus on the concept, as most of us
seem to agree about the benefits a mechanism like PCS can bring to the
core development process in general.
It also appears that PCS is not
33 matches
Mail list logo