[PHP-DEV] hash_hkdf() manual improvement

[Yasuo Ohgaki]

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 hash_hkdf.xml.
https://gist.github.com/yohgaki/e518898ffda2fe37ab911d7a7fcb1a9f

I've put most aspects discussed in the RFC 5869. If you find anything
that violates RFC 5869 recommendation/suggestion (and/or HMAC
recommendation/suggestion), please let me know.
https://tools.ietf.org/html/rfc5869

Please note that previous discussion for this revealed that there is no
valid example usage that justifies current signature. i.e. Specifying
$length/$info parameter(s) only cannot be common/optimal/recommended
usage.  If any example, I'll add it to the manual.

Corrections/improvements are appreciated.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[Yasuo Ohgaki]

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
yohg...@ohgaki.net

[PHP-DEV] BAD Benchmark Results for PHP Master 2017-06-06

[lp_benchmark_robot]

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
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.21% -0.05%  2.63%  
  8.50%
:-|   Drupal 7.36 cgi -T1  0.19% -0.04%  0.28%  
  5.06%
:-|   MediaWiki 1.23.9 cgi -T5000  0.08% -0.49%  2.17%  
  4.34%
:-|   bench.php cgi -T100  0.00% -0.99% 46.04%  
  4.01%
:-|  micro_bench.php cgi -T10  0.01%  0.10% 21.42%  
  3.24%
:-(  mandelbrot.php cgi -T100  0.04% -1.85% 43.27%  
  3.78%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-06-06/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[li...@rhsoft.net]

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?
https://wiki.php.net/rfc/deprecate-bareword-strings


have you seen any valid uecase for that in the past 15 years which was 
not a typo in a constant name or forgotten quotes?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Basic string comparison functions still use old parameter parsing API

[Benjamin Coutu]

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 comparison functions still use old 
parameter parsing API

> 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 functions in
> > ext/standard/string.c such as "substr_compare", "strtok",
> > "str(i)str", "str(i)pos", "strr(i)pos", "strrchr" that already
> > consistently use the new efficient macro-based API.
> > 
> > I think one can consider "str(n)cmp" and "str(n)casecmp", etc. at
> > least as important as "substr_compare", especially considering that
> > these are wrappers around very basic functions that often get called
> > in very hot code or inside tight loops (e.g. sorting). I therefore
> > recommend changing those 4 functions in Zend/zend_builtin_functions.c
> > to use ZEND_PARSE_PARAMETERS_* macros for PHP 7.2.
> > 
> > What do you think?
> > 
> 
> Help? :)
> 
> https://github.com/php/php-src/pull/2565
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] preg_match() option for anchored offset?

[Nikita Popov]

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 = '/^def/';
> $offset = 3;
> preg_match($pattern, substr($subject, $offset), $matches);
>
> In other words, use substr() to copy the entire remainder of the string.
>
> I just wrote a simple SQL parser tonight, and had to use this approach,
> which (I imagine) must be pretty inefficient?
>
> I'd like to be able to do the following:
>
> $subject = "abcdef";
> $pattern = '/^def/';
> $offset = 3;
> preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);
>
> This new option would make the ^ anchor work from the given $offset, which
> allows me to parse the entire $subject without copying anything.
>
> Thoughts?
>

You are looking for the \G anchor or the A modifier.

Nikita

Re: [PHP-DEV] preg_match() option for anchored offset?

[Rowan Collins]

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;
 preg_match($pattern, substr($subject, $offset), $matches);

In other words, use substr() to copy the entire remainder of the string.

I just wrote a simple SQL parser tonight, and had to use this approach,
which (I imagine) must be pretty inefficient?

I'd like to be able to do the following:

 $subject = "abcdef";
 $pattern = '/^def/';
 $offset = 3;
 preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);

This new option would make the ^ anchor work from the given $offset, which
allows me to parse the entire $subject without copying anything.

Thoughts?



How would you propose to implement this? Is it something PCRE already 
supports? Or would you manipulate the subject string pointer at the 
point it's passed down? The latter approach seems doable, but I'm not 
sure if there are any subtle gotchas.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] preg_match() option for anchored offset?

[Rasmus Schultz]

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 other words, use substr() to copy the entire remainder of the string.

I just wrote a simple SQL parser tonight, and had to use this approach,
which (I imagine) must be pretty inefficient?

I'd like to be able to do the following:

$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);

This new option would make the ^ anchor work from the given $offset, which
allows me to parse the entire $subject without copying anything.

Thoughts?

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> 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 
wrote:

>
> > 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 supporting arrow functions, like
> > Javascript & HACK.
> >
> > I also recall from earlier discussions, that with less keystrokes it's
> easier
> > to read when an arrow function is embedded / chained into another
> > expression / statement / function call.
> >
>
>
> I think its pretty clear my pref is/was #2, but when compared to the crazy
> alternatives people have been suggesting, which just seem to be “hold down
> shift and blindly poke at the non-letter keys for a while”, the `fn($a, $b)
> => $a + $b ** $c` syntax suddenly becomes an acceptable compromise.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Basic string comparison functions still use old parameter parsing API

[Fleshgrinder]

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 functions in
> ext/standard/string.c such as "substr_compare", "strtok",
> "str(i)str", "str(i)pos", "strr(i)pos", "strrchr" that already
> consistently use the new efficient macro-based API.
> 
> I think one can consider "str(n)cmp" and "str(n)casecmp", etc. at
> least as important as "substr_compare", especially considering that
> these are wrappers around very basic functions that often get called
> in very hot code or inside tight loops (e.g. sorting). I therefore
> recommend changing those 4 functions in Zend/zend_builtin_functions.c
> to use ZEND_PARSE_PARAMETERS_* macros for PHP 7.2.
> 
> What do you think?
> 

Help? :)

https://github.com/php/php-src/pull/2565

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Fleshgrinder]

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 timing, I will propose it again when RFCs for 8.0
> are relevant.
> 
> Thanks,
> Pedro
> 

It does not loose relevance just because the implementation is
postponed. On the contrary, we could directly start advertising that
change, which is super useful to the PHP ecosystem because they can
prepare their code for the change.

The change you are proposing is absolutely necessary, and it is a great
initiative of yours! :)

However, the possibility of introducing this kind of change in a minor
is dangerous. I am usually against almost all of these changes, but in
favor of deprecation to fix more of these unexpected features.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Pedro Magalhães]

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 you or your
> work, as I'd also like to change such inconsistent behavior, but the
> probability of BC break is too high, IMO.
>

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 timing, I will propose it again when RFCs for 8.0
are relevant.

Thanks,
Pedro

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Rowan Collins]

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
>
>> >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
>>
>>
>> I'm sorry, I don't follow. What rule is broken, incidentally or
>> explicitly, by that RFC?
>>
>
>The page that was already mentioned on this thread:
>https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly
>states
>the following:
>
>x.y.z to x.y+1.z
>> Backward compatibility must be kept
>
>
>However, a number of already implemented RFCs for 7.2 do not follow
>that
>rule strictly:
...
>I don't mean at all that these should not have been accepted.
>Especially
>the ones that initiate a deprecation phase. 

Deprecating something is basically the opposite of breaking backwards 
compatibility in a minor release. The entire point of deprecation messages is 
to indicate ahead of time that something will be broken later, but not break it 
yet. Unless you're being purposefully pedantic to try and prove that black is 
white, adding any log message is barely even a functional change, let alone a 
breaking one.

That said, there *are* sometimes RFCs that break the rule. Usually, they get 
feedback regarding the break, just as this one is. Often, they attempt to 
justify an exception to the rule, as I and others have suggested this one 
could. I don't always agree with the way those exceptions are applied 
(too_few_args was one I opposed, for instance).

I hope you can see that saying "well, we allow people to fix spelling mistakes 
in error messages, so we might as well allow changes that completely change the 
behaviour of a core function" is pretty ridiculous. We have a rule, there are 
grey areas, and we try to navigate them; in this case, people are saying the 
RFC has fallen the wrong side of that grey area. If you disagree, feel free to 
comment on this specific case.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Basic string comparison functions still use old parameter parsing API

[Benjamin Coutu]

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 "substr_compare", "strtok", 
"str(i)str", "str(i)pos", "strr(i)pos", "strrchr" that already consistently use 
the new efficient macro-based API.

I think one can consider "str(n)cmp" and "str(n)casecmp", etc. at least as 
important as "substr_compare", especially considering that these are wrappers 
around very basic functions that often get called in very hot code or inside 
tight loops (e.g. sorting). I therefore recommend changing those 4 functions in 
Zend/zend_builtin_functions.c to use ZEND_PARSE_PARAMETERS_* macros for PHP 7.2.

What do you think?

-- 

Benjamin Coutu
ZeyOS, Inc.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Pedro Magalhães]

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 *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
>
>
> I'm sorry, I don't follow. What rule is broken, incidentally or
> explicitly, by that RFC?
>
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

The page that was already mentioned on this thread:
https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly states
the following:

x.y.z to x.y+1.z
> Backward compatibility must be kept


However, a number of already implemented RFCs for 7.2 do not follow that
rule strictly:

   - https://wiki.php.net/rfc/number_format_negative_zero
   - https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts
   - https://wiki.php.net/rfc/deprecate-bareword-strings
   - https://wiki.php.net/rfc/get_class_disallow_null_parameter
   - https://wiki.php.net/rfc/counting_non_countables
   - https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp
   - https://wiki.php.net/rfc/hash-context.as-resource
   - https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
   - As well as some of the RFCs still pending implementation

I don't mean at all that these should not have been accepted. Especially
the ones that initiate a deprecation phase. But it is seems to me that this
RFC does not break any rule that has been upheld strictly up to this point.

Regards,
Pedro

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Rowan Collins]

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 the case for your own RFC?
>https://wiki.php.net/rfc/deprecate-bareword-strings


I'm sorry, I don't follow. What rule is broken, incidentally or explicitly, by 
that RFC?


-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Stephen Reay]

> 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 supporting arrow functions, like
> Javascript & HACK.
> 
> I also recall from earlier discussions, that with less keystrokes it's easier
> to read when an arrow function is embedded / chained into another
> expression / statement / function call.
> 


I think its pretty clear my pref is/was #2, but when compared to the crazy 
alternatives people have been suggesting, which just seem to be “hold down 
shift and blindly poke at the non-letter keys for a while”, the `fn($a, $b) => 
$a + $b ** $c` syntax suddenly becomes an acceptable compromise.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[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?
https://wiki.php.net/rfc/deprecate-bareword-strings

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

[Aaron Piotrowski]

> 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 Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Christoph M. Becker]

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.
> 
> The RFC process is the way that we change the rules, and RFCs are not
> constrained by any previous RFC […]

If that was so, we wouldn't even be bound to the "Voting on PHP
features" RFC[1], which wouldn't make sense, IMHO.

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Rowan Collins]

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 previous decision or constitution, which is
>different from most other countries, where the power of the government
>is limited by constitution.

Even without a written constitution, you can't simply pass something that 
*incidentally* changes a pre-established rule, you have to explicitly make an 
exception or a new rule.

To take the analogy of English Law, if two Acts conflicted without mentioning 
each other, I don't think it would be a foregone conclusion that the newer law 
should be followed. What's more, there are laws that explicitly constrain the 
process of passing other laws - the Parliament Acts, for instance, or the Human 
Rights Act.

If you can simply say "this conflicts with our agreed procedures, but it's 
newer, so the procedures are automatically wrong" then you might as well not 
have any procedures. Saying "this is an acceptable exception to normal 
procedures because..." seems a reasonable minimum requirement.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] About PCS (was : Proposing inclusion of PCS in the 7.2 core distribution)

[Dan Ackroyd]

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.

> Please give examples of core extensions that, in your opinion, are 
> susceptible to be partially or fully converted to PHP.

Uh - I don't really agree that any existing core code should be
converted to PHP. If the code is already there and working as C code,
there are very few benefits converting it to PHP now. If we ever get
around to refactoring how strings are stored in PHP, it's at that
point that converting existing functionality to PHP code might be a
good idea.

> Suggestions to complement existing core extensions (like an additional curl 
> OO layer) are welcome too.

If you want this RFC to pass, I'd strongly recommend having
conversations about adding those as separate RFCs, once the "having
PHP code distributed with PHP" RFC is passed as otherwise the
signal-to-noise ratios will be terrible.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

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, ($obj) -> $var is valid variable property syntax.


Gosh, we really have support for everything. :D That one is even very
important for stuff like `(new A)->f()`.

How about ~> which I at least cannot think of any place it is used at
all. ~ in binary negation and the only place we use it (I checked the
language parser this time to make sure).

I really dislike the ==> idea. One of the main reasons here is to write
less and it looks too much like => or even >= which I really don't like.

 ($a, $b) ==> $a >= $b

 ($a, $b) ~> $a >= $b



I can get behind using the tilde. Keeps it concise, but it's visually
different than existing syntax, making it easier to recognize (IMO).


I think ~>was a proposal in the short closure RFC. Personally I liked it,
but could also live with ==>. I recall there was a discussion about how
easy it was to use tilde on different keyboards / languages. So at that
point the discussion was about either ~> or ==> for syntax.

But back to Levi's list it looks like, at least to me that option 2 & 4 are
off the table. Leaving option 3 & 1, maybe also option 5.

Do you think this is a reasonable assumption?

Also some other proposals has arisen, like using lamda instead of fn as
a keyword and lastly the ~> one.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

As someone who sees limited appeal in short closures (Ok, they may make for 
slightly simpler constructs that are slightly too complex for a regular 
“collect” type collection method), I see a *lot* of people spending a *lot* of 
time to save typing 8 characters (function).

If this feature truly is about making it easier to read, then that should be your goal: 
make it easy to mentally parse, basically instantly. Given that even proponents of the 
approach are admitting the syntax can get quite hard to understand quickly, perhaps 
it’s time to accept that “more characters” !== “harder to read & understand” and 
importantly, “less characters” !== “easier to read & understand”.

How long does it take someone to type function? A second, maybe two? How many 
times are other people going to read that, once it’s been written?


Or maybe I’ve got it all wrong, and the goal is literally to save 8 keystrokes. 
If that’s the case, please update the RFC accordingly, to make it clear what 
the motivations are


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 supporting arrow functions, like
Javascript & HACK.

I also recall from earlier discussions, that with less keystrokes it's 
easier

to read when an arrow function is embedded / chained into another
expression / statement / function call.

r//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

[Sebastian Bergmann]

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

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Dan Ackroyd]

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 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 previous decision or constitution, which is
different from most other countries, where the power of the government
is limited by constitution.

It behooves people to pay attention to RFCs announced on this list,
and to raise their concerns during the comment phase - not to ask for
"why is this is being allowed" only when the voting starts. To be
clear, I'm referring to some of the more dramatic twitter
communications rather than any emails to this list.

Also, I'd be more comfortable with this targeting PHP 8 - though I'm
hoping someone would demonstrate some actual code that will break,
which would make it easier to decide, rather than just people claiming
stuff might break.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add openssl_pkcs7_read and extend openssl_pkcs7_verify

[Jelle van der Waa]

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 the addition of openssl_pkcs7_read and
> > extending
> > > > openssl_pkcs7_verify to also return a PKCS7 structure. The reasoning
> > for
> > > > the addition of these functions is the requirement at work to obtain
> > the
> > > > CA certificates usually send along with a signed email. The CA
> > > > certificates are required for OCSP verification (which is currently
> > done
> > > > in pure PHP, I also would like to see this added in PHP in the future).
> > > >
> > > > It is currently impossible to acquire the CA certificates with the
> > > > openssl functions which PHP provides, I've also found a bug report
> > > > requesting the ability to read a PKCS7 blob. [1]
> > > >
> > > > To summarize, I would propose to add an optional parameter to
> > > > openssl_pkcs7_verify which takes a string that defines the location
> > > > where the PKCS7 blob should be stored.
> > > >
> > > > $pkcs7 = "chain.pk7";
> > > > openssl_pkcs7_verify($file, PKCS7_NOVERIFY, $outfile, [], $outfile,
> > > > $content, $pkcs7);
> > > >
> > > > To be able to read the blob, I would propose a new function
> > > > openssl_pkcs7_read which returns an array of strings containing the PEM
> > > > certificates in the PKCS7 blob. I've based the naming and behaviour on
> > > > openssl_pkcs12_read.
> > > >
> > > > openssl_pkcs7_read($pkcs7, $data);
> > > > var_dump($data);
> > > >
> > > > I've implemented the above mentioned changes in my fork of PHP, mind
> > > > that the code isn't ready for a PR yet since there are some styling
> > > > issues, possible memory leaks and of course missing tests. The code
> > > > however works as a proof of concept. [2]
> > > >
> > > > For further background information, obtaining the pk7 output can be
> > done
> > > > with the 'openssl' tool:
> > > >
> > > > openssl smime -verify -pk7out  -in signed_email.eml  > foo.pkcs7
> > > > openssl pkcs7 -print_certs -in foo.pkcs7
> > > >
> > > >
> > > It seems reasonable from the quick look.
> > >
> > > I don't think we need RFC unless there are some objections. Once it's
> > > ready, PR should be enough IMHO.
> >
> > Thanks, this is my first contributing a feature to PHP and from reading
> > the wiki an RFC was the method to introduce new features.
> >
> > Offtopic, I also want to later add string based instead of file based
> > openssl_pkcs7_* functions. Do I need to create an RFC for it?
> >
> >
> First of all, it's really great that you contribute to this so thanks!

No problem, we've so far build our application with S/MIME support on
PHP and it worked so far :-)

> I think that for changes like this, it's best to first open PR. When the PR
> is ready and all issues resolved, then it should be announced on this
> mailing list and then see if there are no objections. If there are not, it
> should be fine to merge it IMHO. Otherwise if there is no agreement, it
> probably needs RFC. :) I think that RFC makes sense either when the feature
> is complex or when people are not in agreement about it.

Ok, I'm open to feedback! I've opened the PR 
https://github.com/php/php-src/pull/2563

Another thing I would want to work on is making the openssl_pkcs7_*
functions in memory instead of file based. This would increase the
security concerns since that means it won't save plaintext temporarily to
file. 

An attempt for that has been made in a PR, but was closed. Is the PR on
the right 'track' or can the current functions change to accept either a
string or a filename? (I'm not 100% if PHP internals allow that) or if
it's really wanted. [1]

[1] https://github.com/php/php-src/pull/560

-- 
Jelle van der Waa

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[François Laupretre]

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 minor one. This is not against you or 
your work, as I'd also like to change such inconsistent behavior, but 
the probability of BC break is too high, IMO.


Regards

François

Le 07/06/2017 à 14:19, Christoph M. Becker a écrit :

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 find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383

Voting is open from now until 20/6/2017 18:00 UTC.

I don't think that the current behavior makes much sense, but since it
is well documented and it isn't a bug, changing it in a minor version
wouldn't comply to our release process[1].  Therefore, I've voted
against, but I'd be happy to see this improvement in PHP 8.

[1] 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Fix for NumberFormatter did not work properly when restored from session

[Andrew Nester]

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  
> As it became clear after discussion under proposed pull request here 
> https://github.com/php/php-src/pull/2378 
>  
> there is no single way how to handle serialization of internal classes.
> 
> As Nikita Popov proposed it might be good to add 
> “get_properties_for_serialize handler (or similar), which is a variant of 
> get_properties that is used for serialization (and returns a temporary HT). 
> This would allow us to use wakeup-based unserialization without leaking 
> additional (PHP-level) properties.”
> 
> Thanks!
> 
> Andrew Nester

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

[Marco Pivetta]

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:

> 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,
>>>
>>> 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 the RFC here: https://wiki.php.net/rfc/negative_array_index
>>> The previous discussion: https://externals.io/thread/712
>>> And the PR (also some discussion): https://github.com/php/php-src
>>> /pull/2383
>>>
>> I voted no because of the BC break.
>>
>> cheers,
>> Derick
>>
>>
>>
>

[PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Christoph M. Becker]

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 find the RFC here: https://wiki.php.net/rfc/negative_array_index
> The previous discussion: https://externals.io/thread/712
> And the PR (also some discussion): https://github.com/php/php-src/pull/2383
> 
> Voting is open from now until 20/6/2017 18:00 UTC.

I don't think that the current behavior makes much sense, but since it
is well documented and it isn't a bug, changing it in a minor version
wouldn't comply to our release process[1].  Therefore, I've voted
against, but I'd be happy to see this improvement in PHP 8.

[1] 

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

[François Laupretre]

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,

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 the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383

I voted no because of the BC break.

cheers,
Derick

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

[Derick Rethans]

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 the RFC here: https://wiki.php.net/rfc/negative_array_index
> The previous discussion: https://externals.io/thread/712
> And the PR (also some discussion): https://github.com/php/php-src/pull/2383

I voted no because of the BC break.

cheers,
Derick
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] About PCS (was : Proposing inclusion of PCS in the 7.2 core distribution)

[François Laupretre]

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 ready for an official release yet. Among 
others, we need to refine the way PHP code is loaded and registered.


So, here is what I'm proposing :

- Keep enriching the discussion during about 2 weeks. Please give 
examples of core extensions that, in your opinion, are susceptible to be 
partially or fully converted to PHP. Suggestions to complement existing 
core extensions (like an additional curl OO layer) are welcome too. 
Please tell us if a PHP implementation of these features already exists 
somewhere. I would be especially interested by a PHP implementation of 
the PDO generic layer...


- Then, I'll write an RFC summarizing the discussion. The RFC will list 
blocking and non-blocking issues, as well as an indicative timeline. 
Target for an initial release will be 7.3. It should leave enough time 
to solve blocking issues and start converting some existing code to PHP.


- This RFC will then be voted upon. The vote will just ensure we agree 
on the concept and the objectives. It won't authorize the final merge in 
advance. This will be validated by another vote when the implementation 
to release is ready. The objective is to avoid restarting the whole 
discussion when we're ready for a release.


Regards

François

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php