Re: [PHP-DEV] header() removes all header of the same name.

[Stanislav Malyshev]

Hi!

> There is 2 issues.
>   - header() removes all headers of the same name including 'Set-Cookie'
>   - header() ignores replace flag. (This one is easy to fix)

We have the flag, so if it doesn't work it should be fixed. Also, one
should use setcookie() for cookies, usually.

> Possible resolutions:
> 
>  - Prohibit 'Set-Cookie' for header() and force users to use setcookie()
>  - Mitigate by disabling replace flag by default. (This is not a good idea, 
> IMO)

I don't think we should do either.

> I would like to prohibit 'Set-Cookie' by header() because it may
> remove session ID cookie as well as auto login cookie, etc. If we
> leave released version as it is now, I would like to prohibit
> 'Set-Cookie' by header() in PHP 7.1.

I don't think it's a good idea. If somebody is using header(), it should
work like header() works. If you don't like how it works, use setcookie.

> Problem with this may be that user cannot modify 'Set-Cookie' header
> line as user want.
> 
> $ php -r 'setcookie("REMEMBERME=value; expires=Sat, 03-Sep-2020
> 05:38:43 GMT; path=/; domain=aaa");'
> PHP Warning:  Cookie names cannot contain any of the following '=,;
> \t\r\n\013\014' in Command line code on line 1

You are using setcookie() wrong here. See: http://php.net/setcookie

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

I've committed the safe part of the patch (almost your original idea).


http://git.php.net/?p=php-src.git;a=commitdiff;h=9ded1b4edbb140520e060de597267b3cb439f4c4


The part related to HASH_FLAG_LONG_KEYS/HASH_FLAG_STRING_KEYS is here


https://gist.github.com/dstogov/059c73e7c732fe55110ebf0ca18b4859


as I said, in current state, it makes reduction instead of improvement.

Probably, if we find more use cases for these flags, it may make improvement.


Thanks. Dmitry.



From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 9:58:01 PM
To: Dmitry Stogov; Xinchen Hui; Nikita Popov; Joe Watkins; Bob Weinand; Andrea 
Faulds
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Dmitry,

On second thought, I might have dismissed your HASH_FLAG_*_KEYS idea 
prematurely.

Of course we will have to set/unset the flag in parts of the code that are very 
hot and naturally that will lead to a regression in terms of CPU instructions. 
But in regards to your idea of possibly eliminating redundant checks on every 
loop iteration, I think it could be interesting. It's a tradeoff between 
maintaining the necessary flags and avoiding repeatedly iterating over 
branches. Given that bitwise operations on these flags are just about the 
cheapest operations the CPU can perform (no pipeline stalls and flags usually 
already in L1 cache at that point), and branching inside a loop being extremely 
costly (with the risk of pipeline stalls caused by branch miss prediction, 
which might even happen repeatedly, and EXPECTED/UNEXPECTED macros undesirable 
in most of these cases), choosing to maintain those flags on write operations 
in order to speed up read operations suddenly looks much more appealing. In 
many operations that deal with the hash table in bulk we might even be able to 
set the flag just once upfront. So maybe we should investigate further. Your 
quick test is not conclusive because you have effectively only benchmarked the 
negatives without settling it with the positives.

I don't know wether the additional code complexity is worth the effort though. 
Personally I'd like to focus on getting more out of the packed hash table case, 
meaning trying to preserve the packed characteristics and utilizing dedicated 
code paths as much as possible throughout the entire code base while using the 
existing infrastructure to do so without additional overhead. Packed arrays are 
very ubiquitous after all, and as HT_IS_PACKED always implicates 
HASH_FLAG_LONG_KEYS, there is not that great of a need for the latter if we can 
ensure to use packed arrays wherever possible.

On another note, and this comes without any caveats, we could at least use 
HT_IS_WITHOUT_HOLES to get rid of repeated checks for Z_TYPE(p->val) == 
IS_UNDEF inside loops. This would not entail any overhead on write. What do you 
think?

Cheers,

Benjamin

== Original ==
From: Dmitry Stogov 
To: Benjamin Coutu , Xinchen Hui , 
Nikita Popov , Joe Watkins , "Bob 
Weinand" , Andrea Faulds 
Date: Wed, 19 Oct 2016 18:02:53 +0200
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

This is an option.

If nobody propose a better solution, I'll prepare the patch tomorrow (this 
solution won't make BC breaks at all).

BTW: I think, HASH_FLAG_*_KEYS may be used to eliminate redundant checks on 
every loop iteration in some functions.

Thanks. Dmitry.


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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Benjamin Coutu]

Hi Dmitry,

On second thought, I might have dismissed your HASH_FLAG_*_KEYS idea 
prematurely.

Of course we will have to set/unset the flag in parts of the code that are very 
hot and naturally that will lead to a regression in terms of CPU instructions. 
But in regards to your idea of possibly eliminating redundant checks on every 
loop iteration, I think it could be interesting. It's a tradeoff between 
maintaining the necessary flags and avoiding repeatedly iterating over 
branches. Given that bitwise operations on these flags are just about the 
cheapest operations the CPU can perform (no pipeline stalls and flags usually 
already in L1 cache at that point), and branching inside a loop being extremely 
costly (with the risk of pipeline stalls caused by branch miss prediction, 
which might even happen repeatedly, and EXPECTED/UNEXPECTED macros undesirable 
in most of these cases), choosing to maintain those flags on write operations 
in order to speed up read operations suddenly looks much more appealing. In 
many operations that deal with the hash table in bulk we might even be able to 
set the flag just once upfront. So maybe we should investigate further. Your 
quick test is not conclusive because you have effectively only benchmarked the 
negatives without settling it with the positives.

I don't know wether the additional code complexity is worth the effort though. 
Personally I'd like to focus on getting more out of the packed hash table case, 
meaning trying to preserve the packed characteristics and utilizing dedicated 
code paths as much as possible throughout the entire code base while using the 
existing infrastructure to do so without additional overhead. Packed arrays are 
very ubiquitous after all, and as HT_IS_PACKED always implicates 
HASH_FLAG_LONG_KEYS, there is not that great of a need for the latter if we can 
ensure to use packed arrays wherever possible.

On another note, and this comes without any caveats, we could at least use 
HT_IS_WITHOUT_HOLES to get rid of repeated checks for Z_TYPE(p->val) == 
IS_UNDEF inside loops. This would not entail any overhead on write. What do you 
think?

Cheers,

Benjamin

== Original ==
From: Dmitry Stogov 
To: Benjamin Coutu , Xinchen Hui , 
Nikita Popov , Joe Watkins , "Bob 
Weinand" , Andrea Faulds 
Date: Wed, 19 Oct 2016 18:02:53 +0200
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

This is an option.

If nobody propose a better solution, I'll prepare the patch tomorrow (this 
solution won't make BC breaks at all).

BTW: I think, HASH_FLAG_*_KEYS may be used to eliminate redundant checks on 
every loop iteration in some functions.

Thanks. Dmitry.


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

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

[Leigh]

On Wed, 5 Oct 2016 at 20:11 Derick Rethans  wrote:

> It should be migrated properly, and also to GIT.
>

Hi Ferenc,

Can you create a php.net hosted git repository for this (I guess under the
pecl/security namespace), and grant karma to le...@php.net for it.

Sorry for picking on you personally. I don't know who else can do this :)

Cheers,

Leigh.

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-10-19

[lp_benchmark_robot]

Results for project PHP master, build date 2016-10-19 06:25:32+03:00
commit: 0ffd0a0
previous commit:0a67b29
revision date:  2016-10-19 01:14:15+02: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.10%  0.10%  0.31%  
  7.52%
:-)   Drupal 7.36 cgi -T1  0.13%  1.32% -0.81%  
  4.68%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11%  0.03%  0.51%  
  3.74%
:-)   bench.php cgi -T100  0.16%  2.81% 30.89%  
  1.91%
:-)  micro_bench.php cgi -T10  0.13%  2.80% 14.13%  
  2.94%
:-|  mandelbrot.php cgi -T100  0.06%  0.63% 31.73%  
  4.34%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2016-10-19/

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] [RFC] Driver-Specific PDO Param Types

[Lester Caine]

On 18/10/16 23:05, Adam Baratz wrote:
> Please share your feedback. I'm happy to hear thoughts about the pdo_dblib
> example, but the RFC is more about the possibility of driver-specific types
> than these particular ones.

The whole point of PDO was that anything that was not available across
ALL drivers would be emulated in some way, or flagged in a way that does
not break code, so nothing should be added specifically targeting a
particular driver if it will cause problems when someone selects a
different driver to run the same application.

The question today is if PDO is actually the right base to be building
on, or should a better attempt be made at solving the cross database
problems. ADOdb is still the better benchmark for a lot of the 'loose
ends' that plague PDO.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

This is an option.


If nobody propose a better solution, I'll prepare the patch tomorrow (this 
solution won't make BC breaks at all).


BTW: I think, HASH_FLAG_*_KEYS may be used to eliminate redundant checks on 
every loop iteration in some functions.


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 6:51:00 PM
To: Dmitry Stogov; Xinchen Hui; Nikita Popov; Joe Watkins; Bob Weinand; Andrea 
Faulds
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

I would suggest we stickt to my original proposal for HT_IS_FULLY_PACKED (alias 
HT_IS_PACKED + HT_IS_WITHOUT_HOLES) for now, because that doesn't require 
additional overhead. At this point I don't care too much about HASH_FLAG_*_KEYS 
because (just as you said) we would have to keep them consistent and would add 
overhead in very hot code paths (e.g. _zend_hash_add_or_update_i). I cannot 
think of too many use cases for HASH_FLAG_*_KEYS either.

== Original ==
From: Dmitry Stogov 
To: Benjamin Coutu , Xinchen Hui , 
Nikita Popov , Joe Watkins , "Bob 
Weinand" , Andrea Faulds 
Date: Wed, 19 Oct 2016 17:25:32 +0200
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property


I've updated the patch with few use cases 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

The patch doesn't show any visible speed difference, but in term of "CPU 
instructions" (measured by callgrind) it makes 0.3% regression on 100 requests 
to Wordpress home page.

This is caused by keeping HASH_FLAG_STRING_KEYS/HASH_FLAG_LONG_KEYS consistency.


So, I'm not so optimistic about this now...


Please, think if we need this, and if it's possible to make this better.


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 5:31:01 PM
To: Dmitry Stogov; Xinchen Hui; Nikita Popov; Joe Watkins
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Dmitry,

there is a typo in line 78 of your patch 
(https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d#file-ht_flags-01-diff-L78).
 It should be HT_IS_PACKED(ht) instead of HT_IS_PACKED(HT).

Tahnks,
Ben

== Original ==
From: Dmitry Stogov 
To: Benjamin Coutu , Xinchen Hui , 
Nikita Popov , Joe Watkins 
Date: Wed, 19 Oct 2016 14:53:31 +0200
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property


The main API/BC changes implementation: 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

All tests passed. Performance is not affected (+1 CPU instruction on each *new* 
element insertion)

If it's OK and allowed, after committing this, I'll add few usages of these new 
defines for optimization.

All of them are going to be self-containing changes to particular functions 
implementation.


Thanks. Dmitry.


From: Dmitry Stogov 
Sent: Wednesday, October 19, 2016 2:20:12 PM
To: Benjamin Coutu; Xinchen Hui; Nikita Popov; Joe Watkins
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Benjamin,


I think this is great idea!

Let me check that can we get from this, and if we may add this into PHP-7.1 (it 
may be to late).


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 1:45:00 PM
To: Xinchen Hui; Dmitry Stogov; Nikita Popov
Cc: PHP Internals
Subject: [PHP-DEV] Exploit fully packed array/hash property

Hello everyone,

I've identified a few more array/hash use cases where it might make sense to 
introduce special short circuit logic for packed arrays.

Specifically, there is an additional property of certain packed arrays (apart 
from being packed obviously) that we can utilize: A packed array with nNumUsed 
equal to nNumOfElements must be consecutively indexed from zero onward without 
any gaps (no IS_UNDEF). Let's call this special pure form of a packed array a 
"fully packed array".

Earlier I have posted on how this convenient property could speed things up for 
array_slice, even if preserved_keys=true (for the offset=0 case), see 
https://marc.info/?l=php-internals=147048569215717=2

I therefore propose to introduce the following two new macros in 
/Zend/zend_types.h in order to make it easier for developers to introduce 
special packed (or fully packed) array logic:

#define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
#define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed == 
(ht)->nNumOfElements)

With this we can easily speed things up (and more importantly preserve the 
packed array characteristics) for the common case of 

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

I've updated the patch with few use cases 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

The patch doesn't show any visible speed difference, but in term of "CPU 
instructions" (measured by callgrind) it makes 0.3% regression on 100 requests 
to Wordpress home page.

This is caused by keeping HASH_FLAG_STRING_KEYS/HASH_FLAG_LONG_KEYS consistency.


So, I'm not so optimistic about this now...


Please, think if we need this, and if it's possible to make this better.


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 5:31:01 PM
To: Dmitry Stogov; Xinchen Hui; Nikita Popov; Joe Watkins
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Dmitry,

there is a typo in line 78 of your patch 
(https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d#file-ht_flags-01-diff-L78).
 It should be HT_IS_PACKED(ht) instead of HT_IS_PACKED(HT).

Tahnks,
Ben

== Original ==
From: Dmitry Stogov 
To: Benjamin Coutu , Xinchen Hui , 
Nikita Popov , Joe Watkins 
Date: Wed, 19 Oct 2016 14:53:31 +0200
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property


The main API/BC changes implementation: 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

All tests passed. Performance is not affected (+1 CPU instruction on each *new* 
element insertion)

If it's OK and allowed, after committing this, I'll add few usages of these new 
defines for optimization.

All of them are going to be self-containing changes to particular functions 
implementation.


Thanks. Dmitry.


From: Dmitry Stogov 
Sent: Wednesday, October 19, 2016 2:20:12 PM
To: Benjamin Coutu; Xinchen Hui; Nikita Popov; Joe Watkins
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Benjamin,


I think this is great idea!

Let me check that can we get from this, and if we may add this into PHP-7.1 (it 
may be to late).


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 1:45:00 PM
To: Xinchen Hui; Dmitry Stogov; Nikita Popov
Cc: PHP Internals
Subject: [PHP-DEV] Exploit fully packed array/hash property

Hello everyone,

I've identified a few more array/hash use cases where it might make sense to 
introduce special short circuit logic for packed arrays.

Specifically, there is an additional property of certain packed arrays (apart 
from being packed obviously) that we can utilize: A packed array with nNumUsed 
equal to nNumOfElements must be consecutively indexed from zero onward without 
any gaps (no IS_UNDEF). Let's call this special pure form of a packed array a 
"fully packed array".

Earlier I have posted on how this convenient property could speed things up for 
array_slice, even if preserved_keys=true (for the offset=0 case), see 
https://marc.info/?l=php-internals=147048569215717=2

I therefore propose to introduce the following two new macros in 
/Zend/zend_types.h in order to make it easier for developers to introduce 
special packed (or fully packed) array logic:

#define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
#define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed == 
(ht)->nNumOfElements)

With this we can easily speed things up (and more importantly preserve the 
packed array characteristics) for the common case of array_slice($packed_array, 
$offset=0, $length, $preserved_keys=true) by using the follwing snippet for 
https://github.com/php/php-src/blob/master/ext/standard/array.c#L2906 :

if (preserve_keys ? (offset == 0 && HT_IS_FULLY_PACKED(Z_ARRVAL_P(input))) : 
HT_IS_PACKED(Z_ARRVAL_P(input)))
  ... ZEND_HASH_FILL_PACKED ...

Another example where this could come in handy involves the encoding of JSON. 
For every array that it encodes, json_encode must first detemine wheter the 
array contains string keys or is not consecutively indexed, so that it can 
decide wheter to use a JSON object or a plain JSON array. That is accomplished 
through php_json_determine_array_type in /ext/json/json_encoder.c. That code 
currently has to iterate through the array until it finds a string key or a 
non-consecutive index (which in the worst case would mean iterating through the 
entire array).

Now, for fully packed arrays we can short circuit things and jump directly to 
the conclusion of it being a real plain old array, if it is packed and we can 
prove it has no gaps. That can of course easily be done via the new 
HT_IS_FULLY_PACKED macro. We can improve this code for a large amount of arrays 
with the following simple snippet for 
https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L38 :

if (HT_IS_FULLY_PACKED(myht))
  return PHP_JSON_OUTPUT_ARRAY;

I'll be happy to make an effort to screen the 

Re: [PHP-DEV] Performance drops after some time, PHP7-FPM + Docker

[Rasmus Lerdorf]

>
> The output of the perf diff is quite poor I think, here's the mainline :
> 35.90%  +44.94%  php-fpm [.] 0x00042412
> 10.72%   -6.05%  libc-2.19.so[.] 0x00079030
>  9.71%   -9.34%  newrelic.so [.] 0x00030980
>  3.81%   -3.47%  [kernel.kallsyms]   [k] ipt_do_table
>  2.56%   -2.02%  [kernel.kallsyms]   [k] nf_iterate
>  2.32%   -1.99%  opcache.so  [.] 0x8cec
>  1.44%   [kernel.kallsyms]   [k] update_cfs_shares
>  1.42%   [kernel.kallsyms]   [k] __bpf_prog_run
>  1.28%   [vdso]  [.] __vdso_gettimeofday
>
> How could I provide more info ?
>

Yes, not much to go on there. But newrelic.so stands out to me. Can you try
removing newrelic and see if it still happens?

If it does, your next step is to look at the timing of a request. I usually
do that with something like this:

sudo strace -Ff -ttt -T -p  2>&1 | tee strace_output_file

Do that on a fast process and on a slow process and let it run for a little
while to the point where you think you have captured similar requests in
both runs, then have a look at the timing between syscalls in both and see
if you can spot if it is an isolated delay in a certain part of the request
or if it is just an overall slowdown.

I would also run:

vmstat 1

both before and after. This gives you a picture of the overall health of
your server. The si/so columns, for example, will tell you if you are
swapping. If something has eaten a ton of memory and your system has
started swapping more than before then that could also explain this.

-Rasmus

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

On 17 October 2016 at 21:57, Nikita Popov  wrote:

> > I'm not sure I understand the motivation for throwing a deprecation
> notice
> > instead of a warning. In particular, what is the action that will be
> taken
> > here in the next major version?
>

On 18 October 2016 at 12:53, Christoph M. Becker  wrote:
 is

> supposed to introduce a new E_WARNING in PHP 7.2.
>
> And yes, there is a (small) BC break, but even E_DEPRECATED might be
> regarded as such.
>


Thank you both for the feedback, I've gone with a warning now, I'll put the
RFC to vote in a few days

https://wiki.php.net/rfc/counting_non_countables

Re: [PHP-DEV] Re: Constants for better double edge case handling

[Andrea Faulds]

Hi,

Anatol Belski wrote:

Anatol Belski wrote:

Producing INF. There's currently no explicit way to produce INF and
NAN, whereby NAN is gettable with sqrt(-1).

echo PHP_DBL_MAX*PHP_DBL_MAX, " ", -PHP_DBL_MAX*PHP_DBL_MAX; INF

-INF

I'm not sure I understand this use-case. We already have the INF and NAN
constants for obtaining those values, and the standard IEEE 754 operations
which produce these values are implemented (1/0 for INF, 0/0 for NAN,

etc.)



Ah, so then it is fine, thanks for the education. Then it'd stay by DBL_DIG
and DBL_EPSILON. While DBL_MAX/ DBL_MIN could still be useful in some case
(fe one would want to explicitly know the values), in most case it'd be
covered by INF.


It can't hurt to add them anyway, though.

--
Andrea Faulds
https://ajf.me/

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

RE: [PHP-DEV] Re: Constants for better double edge case handling

[Anatol Belski]

Hi Andrea,

> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, October 19, 2016 2:49 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: Constants for better double edge case handling
> 
> Hi Anatol,
> 
> Anatol Belski wrote:
> > Producing INF. There's currently no explicit way to produce INF and
> > NAN, whereby NAN is gettable with sqrt(-1).
> >
> > echo PHP_DBL_MAX*PHP_DBL_MAX, " ", -PHP_DBL_MAX*PHP_DBL_MAX; INF
> -INF
> 
> I'm not sure I understand this use-case. We already have the INF and NAN
> constants for obtaining those values, and the standard IEEE 754 operations
> which produce these values are implemented (1/0 for INF, 0/0 for NAN,
etc.)
> 
Ah, so then it is fine, thanks for the education. Then it'd stay by DBL_DIG
and DBL_EPSILON. While DBL_MAX/ DBL_MIN could still be useful in some case
(fe one would want to explicitly know the values), in most case it'd be
covered by INF. 

Regards

Anatol


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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

I may add comments for HT_IS_FULLY_PACKED() or may be use a better name 
HT_IS_WITHOUT_HOLES()


From: Andrea Faulds 
Sent: Wednesday, October 19, 2016 4:25:31 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Dmitry,

Dmitry Stogov wrote:
> The main API/BC changes implementation: 
> https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d
>
> All tests passed. Performance is not affected (+1 CPU instruction on each 
> *new* element insertion)
>
> If it's OK and allowed, after committing this, I'll add few usages of these 
> new defines for optimization.
>
> All of them are going to be self-containing changes to particular functions 
> implementation.

These proposed HT_HAS_STRING_KEYS_ONLY() and HT_HAS_LONG_KEYS_ONLY()
macros look pretty useful. My patch to fix up array/object casts'
handling of numeric strings could make use of these, for instance. I
would be glad to see this merged.

Do you think HT_IS_FULLY_PACKED() would benefit from an explanatory comment?

Thanks!
--
Andrea Faulds
https://ajf.me/

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

[PHP-DEV] Re: [RFC] OpenSSL BigNum support

[Andrea Faulds]

Hi Sara,

Sara Golemon wrote:

As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.

https://wiki.php.net/rfc/openssl.bignum



If I'm reading the patch correctly, do all the methods accepting BigNums 
also accept PHP integers and strings, including hexadecimal strings?


Also, what happens for floats, or numeric strings with a decimal point 
or exponent? Will it be accepted, rejected, silently truncated? I'm 
guessing it won't produce PHP 7.1's notices and warnings for invalid 
numeric strings (though I don't suggest cloning that specific behaviour, 
an outright error would be better).


Thanks!

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

Thanks Joe. I'll add few optimization and make additional testing, then commit 
in two peaces.


From: Joe Watkins 
Sent: Wednesday, October 19, 2016 4:35:36 PM
To: Dmitry Stogov
Cc: Benjamin Coutu; Xinchen Hui; Nikita Popov; PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Morning Dmitry,

That's what I thought it would look like, that's fine for 7.1 imo.

Cheers
Joe

On Wed, Oct 19, 2016 at 1:53 PM, Dmitry Stogov 
> wrote:

The main API/BC changes implementation: 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

All tests passed. Performance is not affected (+1 CPU instruction on each *new* 
element insertion)

If it's OK and allowed, after committing this, I'll add few usages of these new 
defines for optimization.

All of them are going to be self-containing changes to particular functions 
implementation.


Thanks. Dmitry.


From: Dmitry Stogov >
Sent: Wednesday, October 19, 2016 2:20:12 PM
To: Benjamin Coutu; Xinchen Hui; Nikita Popov; Joe Watkins
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Benjamin,


I think this is great idea!

Let me check that can we get from this, and if we may add this into PHP-7.1 (it 
may be to late).


Thanks. Dmitry.


From: Benjamin Coutu >
Sent: Wednesday, October 19, 2016 1:45:00 PM
To: Xinchen Hui; Dmitry Stogov; Nikita Popov
Cc: PHP Internals
Subject: [PHP-DEV] Exploit fully packed array/hash property

Hello everyone,

I've identified a few more array/hash use cases where it might make sense to 
introduce special short circuit logic for packed arrays.

Specifically, there is an additional property of certain packed arrays (apart 
from being packed obviously) that we can utilize: A packed array with nNumUsed 
equal to nNumOfElements must be consecutively indexed from zero onward without 
any gaps (no IS_UNDEF). Let's call this special pure form of a packed array a 
"fully packed array".

Earlier I have posted on how this convenient property could speed things up for 
array_slice, even if preserved_keys=true (for the offset=0 case), see 
https://marc.info/?l=php-internals=147048569215717=2

I therefore propose to introduce the following two new macros in 
/Zend/zend_types.h in order to make it easier for developers to introduce 
special packed (or fully packed) array logic:

#define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
#define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed == 
(ht)->nNumOfElements)

With this we can easily speed things up (and more importantly preserve the 
packed array characteristics) for the common case of array_slice($packed_array, 
$offset=0, $length, $preserved_keys=true) by using the follwing snippet for 
https://github.com/php/php-src/blob/master/ext/standard/array.c#L2906 :

if (preserve_keys ? (offset == 0 && HT_IS_FULLY_PACKED(Z_ARRVAL_P(input))) : 
HT_IS_PACKED(Z_ARRVAL_P(input)))
  ... ZEND_HASH_FILL_PACKED ...

Another example where this could come in handy involves the encoding of JSON. 
For every array that it encodes, json_encode must first detemine wheter the 
array contains string keys or is not consecutively indexed, so that it can 
decide wheter to use a JSON object or a plain JSON array. That is accomplished 
through php_json_determine_array_type in /ext/json/json_encoder.c. That code 
currently has to iterate through the array until it finds a string key or a 
non-consecutive index (which in the worst case would mean iterating through the 
entire array).

Now, for fully packed arrays we can short circuit things and jump directly to 
the conclusion of it being a real plain old array, if it is packed and we can 
prove it has no gaps. That can of course easily be done via the new 
HT_IS_FULLY_PACKED macro. We can improve this code for a large amount of arrays 
with the following simple snippet for 
https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L38 :

if (HT_IS_FULLY_PACKED(myht))
  return PHP_JSON_OUTPUT_ARRAY;

I'll be happy to make an effort to screen the entire code base in search for 
more cases where this could be useful once this is picked up by a lead core 
developer (maybe Xinchen?) who is willing to commit something on the lines of 
the above.

Any thoughts?

Benjamin

--

Bejamin Coutu
ben.co...@zeyos.com

ZeyOS, Inc.
http://www.zeyos.com

Re: [PHP-DEV] Exploit fully packed array/hash property

[Joe Watkins]

Morning Dmitry,

That's what I thought it would look like, that's fine for 7.1 imo.

Cheers
Joe

On Wed, Oct 19, 2016 at 1:53 PM, Dmitry Stogov  wrote:

> The main API/BC changes implementation: https://gist.github.com/dstogov/
> 429fcc2ba051fdcf774a310c5d6db00d
>
>
> All tests passed. Performance is not affected (+1 CPU instruction on each
> *new* element insertion)
>
>
> If it's OK and allowed, after committing this, I'll add few usages of
> these new defines for optimization.
>
> All of them are going to be self-containing changes to particular
> functions implementation.
>
>
> Thanks. Dmitry.
> --
> *From:* Dmitry Stogov 
> *Sent:* Wednesday, October 19, 2016 2:20:12 PM
> *To:* Benjamin Coutu; Xinchen Hui; Nikita Popov; Joe Watkins
> *Cc:* PHP Internals
> *Subject:* Re: [PHP-DEV] Exploit fully packed array/hash property
>
> Hi Benjamin,
>
>
> I think this is great idea!
>
> Let me check that can we get from this, and if we may add this into
> PHP-7.1 (it may be to late).
>
>
> Thanks. Dmitry.
>
> 
> From: Benjamin Coutu 
> Sent: Wednesday, October 19, 2016 1:45:00 PM
> To: Xinchen Hui; Dmitry Stogov; Nikita Popov
> Cc: PHP Internals
> Subject: [PHP-DEV] Exploit fully packed array/hash property
>
> Hello everyone,
>
> I've identified a few more array/hash use cases where it might make sense
> to introduce special short circuit logic for packed arrays.
>
> Specifically, there is an additional property of certain packed arrays
> (apart from being packed obviously) that we can utilize: A packed array
> with nNumUsed equal to nNumOfElements must be consecutively indexed from
> zero onward without any gaps (no IS_UNDEF). Let's call this special pure
> form of a packed array a "fully packed array".
>
> Earlier I have posted on how this convenient property could speed things
> up for array_slice, even if preserved_keys=true (for the offset=0 case),
> see https://marc.info/?l=php-internals=147048569215717=2
>
> I therefore propose to introduce the following two new macros in
> /Zend/zend_types.h in order to make it easier for developers to introduce
> special packed (or fully packed) array logic:
>
> #define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
> #define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed ==
> (ht)->nNumOfElements)
>
> With this we can easily speed things up (and more importantly preserve the
> packed array characteristics) for the common case of
> array_slice($packed_array, $offset=0, $length, $preserved_keys=true) by
> using the follwing snippet for https://github.com/php/php-
> src/blob/master/ext/standard/array.c#L2906 :
>
> if (preserve_keys ? (offset == 0 && HT_IS_FULLY_PACKED(Z_ARRVAL_P(input)))
> : HT_IS_PACKED(Z_ARRVAL_P(input)))
>   ... ZEND_HASH_FILL_PACKED ...
>
> Another example where this could come in handy involves the encoding of
> JSON. For every array that it encodes, json_encode must first detemine
> wheter the array contains string keys or is not consecutively indexed, so
> that it can decide wheter to use a JSON object or a plain JSON array. That
> is accomplished through php_json_determine_array_type in
> /ext/json/json_encoder.c. That code currently has to iterate through the
> array until it finds a string key or a non-consecutive index (which in the
> worst case would mean iterating through the entire array).
>
> Now, for fully packed arrays we can short circuit things and jump directly
> to the conclusion of it being a real plain old array, if it is packed and
> we can prove it has no gaps. That can of course easily be done via the new
> HT_IS_FULLY_PACKED macro. We can improve this code for a large amount of
> arrays with the following simple snippet for https://github.com/php/php-
> src/blob/master/ext/json/json_encoder.c#L38 :
>
> if (HT_IS_FULLY_PACKED(myht))
>   return PHP_JSON_OUTPUT_ARRAY;
>
> I'll be happy to make an effort to screen the entire code base in search
> for more cases where this could be useful once this is picked up by a lead
> core developer (maybe Xinchen?) who is willing to commit something on the
> lines of the above.
>
> Any thoughts?
>
> Benjamin
>
> --
>
> Bejamin Coutu
> ben.co...@zeyos.com
>
> ZeyOS, Inc.
> http://www.zeyos.com
>
>

Re: [PHP-DEV] Exploit fully packed array/hash property

[Andrea Faulds]

Hi again,

Andrea Faulds wrote:

Second, do you know if any other PHP functions
do a similar check to JSON's php_json_determine_array_type for whether
an array is free of string keys and consecutively indexed? I wonder if
that could be abtracted into a zend_hash.c function.


It seems Dmitry was way ahead of me here. My bad. :)

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Andrea Faulds]

Hi Dmitry,

Dmitry Stogov wrote:

The main API/BC changes implementation: 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

All tests passed. Performance is not affected (+1 CPU instruction on each *new* 
element insertion)

If it's OK and allowed, after committing this, I'll add few usages of these new 
defines for optimization.

All of them are going to be self-containing changes to particular functions 
implementation.


These proposed HT_HAS_STRING_KEYS_ONLY() and HT_HAS_LONG_KEYS_ONLY() 
macros look pretty useful. My patch to fix up array/object casts' 
handling of numeric strings could make use of these, for instance. I 
would be glad to see this merged.


Do you think HT_IS_FULLY_PACKED() would benefit from an explanatory comment?

Thanks!
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Andrea Faulds]

Hi Benjamin,

These are interesting optimisations. I definitely see the usefulness of 
detecting packed arrays and short-circuiting: I've done that in my patch 
to fix object/array casting, in order to avoid wasting time checking for 
the existence of non-string keys, even if (object)[1, 2, 3] is probably 
quite a rare case.


Personally, having macros for this in the Zend API might bother me 
slightly, because it would make it easier to rely on what is essentially 
an implementation detail, and therefore perhaps slightly complicate 
future changes to the hashtable internals.


However, so long as they're only used as hints about the shape of the 
array, I guess this wouldn't be an issue. In any case, I don't know if 
my concern here is worth worrying about.


Two further thoughts. First, are these the best names for the macros? I 
don't know if the meaning of “fully packed array” would be clear without 
an explanatory comment. Second, do you know if any other PHP functions 
do a similar check to JSON's php_json_determine_array_type for whether 
an array is free of string keys and consecutively indexed? I wonder if 
that could be abtracted into a zend_hash.c function.


Thanks!
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] PHP-7.1.0RC4

[Ivan Enderlin]

Thanks!


On 19.10.16 12:48, Joe Watkins wrote:

Morning internals, QA folks,

I would like to announce the availability of PHP-7.1.0RC4.

Downloads: http://downloads.php.net/~krakjoe/

php-7.1.0RC4.tar.bz2
SHA256 hash:
ed2ef6dec04d1f8745b6212c55684cfd1350fad28db4c659ff99e9c6d16d3f36
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJYB0z4AAoJEJZAoYTDlTxVvbsP/RM9VO8U7LABB4F3lWbmo0wW
riCmURs82XUK4x+C+Bq16vpro+cJGISSCaD5YZpWd53DONm0JaB6jWKdw/2aQfVc
Whjd9D+WYL4JgTfJNQgOcIFfTx0fpQnVe0OwT5DqwPrlzHRt3Ek6zeBkXtXtzJM/
eibyFtkK2E7c8NojBgUb64PwHu8e+EjGiMg5m0eiqIZc9Ogg/Fq11/piLkPy3U8A
J+DfoAJhArsNfTWpv87pJhg377yQkapxqYEfpFKGGS+/qA29hqYEwnNnEoXUyuRF
vfs5l56XWexcmOQQA8k9XdTs87+pMoC2GsgtCWxU9HGu/bqseHoeylsXAAz84veL
ePJsZyyf+MK/ksOEBlaMrjct3MEDS7wMKWk2Oqym5po/sdnA+XiKb0l1UNkNTbcp
HqXL9U94QV/NsRDlmboQ/NilYqr3k4YoqMMWYJdqIsmYm5ldTQem+rvuUno8nx8a
byYvdUXXrbbM+hmKX8gGqV0ERfRLUU44xByTqpftJPVTsaisdkTY1hzRwJKTkZOI
gzm9czciPJOUdVuMJEt+tw+wyI6IGcVMFwjVk6Nf2voTtP1t5b9NXR6u/9dMDgJm
bfqbV4ffIMBG7Rf9ggELmcBeK4brfBFSwJYZuoQl7QJprYH/jTbSnkSQ/lkOQDLv
xG9ppUCWmSViKJUzHYLw
=txIc
-END PGP SIGNATURE-


php-7.1.0RC4.tar.gz
SHA256 hash:
8701d826d210abaa0d54d9a8344d14f00f1fb34d918b14e61f4fdd1b19226c46
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJYB0z8AAoJEJZAoYTDlTxVcZUP/3Ot1CVledtqVcsLCLrPnWBj
KxPH999OJy7gwuXQsCHF5QfwZGU1lrc/y9wAIHkaB26FANnkOujhHV6tcMqc03N0
tI26YklI0bZJJ0FDGgh+GH5vQL6Tx5Dxy1KfMB/2BTi0+rjwS5L1qfN8fX4DhWjQ
1TeMkeM+tAkjIlPGoUWzvqzo/n21ANnHwLspQxQgG/+lW8b61UBD00jtXY9XByNS
pCG8q1ebKb+jBMa8fuPdRsxbDOsdqQzPhwIehO6sWy8P+NpdXjwR7+UmO5Wh2EZw
jyiv4Xll4z3rj6X2AVdeVirUv464HQpBFdqZLVu3L4RMx5o6UbLep1nw5DQjpWoZ
PPQzWcGr5DcuTG4d399wC93ti04tmksjOfrLazdAVcJ8zjXpJYYuFlg3kbJnMpqw
a+6pkPtMQIsbAu6Kgc4e+fQmsEIlwjCFhRAA7WDPF+nxuHnun1QnrpsPAZGeQqau
PMj419dxk26NmVKedlofBdn+X9GEJItIaVyHwy1x80qo+yYtJaokzMdnMg6C+KwF
/Zxi5VYzdSAnZX3tSs5BTQ3HzzFC5S3P6UwD8dDZA/ADETxo2vhJyANMFuvGwAH/
uTGjqfi30q3naDFwBbKUeNinLCIR5B8D1ryJy0F1kOIB8rpclFS9UuplCZQ5ie5M
wbP2tQWvhFfuyXoPvfEL
=8IdV
-END PGP SIGNATURE-


php-7.1.0RC4.tar.xz
SHA256 hash:
aa06af4cd4674b4a57969d39566497d700c291f433209f8c83b75ffc1128d258
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJYB00AAAoJEJZAoYTDlTxVcW0P/0FH00FnGMvIUBfkmyPVu6Lh
KeeW9G2Zudy1IXjmjtYJLeQn0ese0aHEHhBgSF83Ukje00QQgI/MGVBF4T05zS8M
agLbqzgHwaKEdZpPBpSrhD8UWJN47F8evti5NtyZmq6VGdNEEwyNgf82sjIn7Hxy
gYJAIRxi7DbGSfff0QQndVl1hkFsvDtjFRHxbymloTwb5edbntYSQxGJJWSg6SXj
TvD85dEI1VP8zznq5CTQFrJVF+YdU7FUIq9Gs4ATKIFqHEzbyRDWC34OF2Au+shW
eboi0ELDR3G4Jf0z1/hBb8i+ovhSOWSmGC/BtESGqF2QGqeoncZwGNGtAoecVZHF
Fok+XVIxSwGFG2Ang7F7rWGCWpqS9PEeQQgrDfuSFER462Ke5tBiFDHvdc2Mm+tZ
dXQsE80TcWxOTFaDGNVt4exwkMW+pIqZPRhr+L4H5XeDsgJWgmHF4OWyZ8h2MzoD
0Qy0Q1vkuV3f52dR+Sc2ySgZ+3+wTOy99omxi9sMcWJDf71EGKVyasBbWXxtd1NK
KHOfdWSTZSeEgG1doSEQVuyYv41m0R4fPE4+w1SIxC9bfmzRtwn71cHckco6Qaua
hv1y6EnbhS2fBjWRIsKrS8HtWu30+IGlBdSflmRnXPH/pzpEB8CEqzPvd//fhubo
Gxnx7odid2/98tvjh3Vg
=YB0l
-END PGP SIGNATURE-

Please see NEWS and UPGRADING for recent changes.

Sorry about the delay.

Cheers
Joe




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

[PHP-DEV] Re: header() removes all header of the same name.

[Andrea Faulds]

Hi Yasuo,

I don't think we should do anything about this beyond maybe warning the 
user in the manual. header() is a generic function for setting headers, 
it would be surprising if it had different behaviour for cookies or 
session cookies. It is possible that use of this function in this way 
may be deliberate.


Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Performance drops after some time, PHP7-FPM + Docker

[Jérémie BORDIER]

Hello Rasmus,

Thank you for the insight. I ran exactly what you said, on the very
same php-fpm process, once just after restarting it almost 2 days ago,
so having fast response time, and one just right now after the "slow
down" issue triggered during the night.

The output of the perf diff is quite poor I think, here's the mainline :
35.90%  +44.94%  php-fpm [.] 0x00042412
10.72%   -6.05%  libc-2.19.so[.] 0x00079030
 9.71%   -9.34%  newrelic.so [.] 0x00030980
 3.81%   -3.47%  [kernel.kallsyms]   [k] ipt_do_table
 2.56%   -2.02%  [kernel.kallsyms]   [k] nf_iterate
 2.32%   -1.99%  opcache.so  [.] 0x8cec
 1.44%   [kernel.kallsyms]   [k] update_cfs_shares
 1.42%   [kernel.kallsyms]   [k] __bpf_prog_run
 1.28%   [vdso]  [.] __vdso_gettimeofday

How could I provide more info ?

Thanks,
Best regards,
Jérémie

On Fri, Oct 14, 2016 at 9:10 PM, Rasmus Lerdorf  wrote:
> On Fri, Oct 14, 2016 at 9:15 PM, Jérémie BORDIER 
> wrote:
>>
>> I don't really know how to investigate further. If you have any
>> pointers on how to help figuring out what's wrong, I'd love to try.
>
>
> I would breakout the Linux perf command for something like this.
>
> Run it like this:
>
> perf record -p  -g
>
> Let that run for some arbitrary amount of time. Start with 10 seconds, or
> so. Then:
>
> perf report -n
>
> That should give you a nice report of what your php-fpm process did for
> those 10 seconds. Now do the same thing when you see the problem and compare
> the reports.
>
> -Rasmus



-- 
Jérémie BORDIER

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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

The main API/BC changes implementation: 
https://gist.github.com/dstogov/429fcc2ba051fdcf774a310c5d6db00d

All tests passed. Performance is not affected (+1 CPU instruction on each *new* 
element insertion)

If it's OK and allowed, after committing this, I'll add few usages of these new 
defines for optimization.

All of them are going to be self-containing changes to particular functions 
implementation.


Thanks. Dmitry.


From: Dmitry Stogov 
Sent: Wednesday, October 19, 2016 2:20:12 PM
To: Benjamin Coutu; Xinchen Hui; Nikita Popov; Joe Watkins
Cc: PHP Internals
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property

Hi Benjamin,


I think this is great idea!

Let me check that can we get from this, and if we may add this into PHP-7.1 (it 
may be to late).


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 1:45:00 PM
To: Xinchen Hui; Dmitry Stogov; Nikita Popov
Cc: PHP Internals
Subject: [PHP-DEV] Exploit fully packed array/hash property

Hello everyone,

I've identified a few more array/hash use cases where it might make sense to 
introduce special short circuit logic for packed arrays.

Specifically, there is an additional property of certain packed arrays (apart 
from being packed obviously) that we can utilize: A packed array with nNumUsed 
equal to nNumOfElements must be consecutively indexed from zero onward without 
any gaps (no IS_UNDEF). Let's call this special pure form of a packed array a 
"fully packed array".

Earlier I have posted on how this convenient property could speed things up for 
array_slice, even if preserved_keys=true (for the offset=0 case), see 
https://marc.info/?l=php-internals=147048569215717=2

I therefore propose to introduce the following two new macros in 
/Zend/zend_types.h in order to make it easier for developers to introduce 
special packed (or fully packed) array logic:

#define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
#define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed == 
(ht)->nNumOfElements)

With this we can easily speed things up (and more importantly preserve the 
packed array characteristics) for the common case of array_slice($packed_array, 
$offset=0, $length, $preserved_keys=true) by using the follwing snippet for 
https://github.com/php/php-src/blob/master/ext/standard/array.c#L2906 :

if (preserve_keys ? (offset == 0 && HT_IS_FULLY_PACKED(Z_ARRVAL_P(input))) : 
HT_IS_PACKED(Z_ARRVAL_P(input)))
  ... ZEND_HASH_FILL_PACKED ...

Another example where this could come in handy involves the encoding of JSON. 
For every array that it encodes, json_encode must first detemine wheter the 
array contains string keys or is not consecutively indexed, so that it can 
decide wheter to use a JSON object or a plain JSON array. That is accomplished 
through php_json_determine_array_type in /ext/json/json_encoder.c. That code 
currently has to iterate through the array until it finds a string key or a 
non-consecutive index (which in the worst case would mean iterating through the 
entire array).

Now, for fully packed arrays we can short circuit things and jump directly to 
the conclusion of it being a real plain old array, if it is packed and we can 
prove it has no gaps. That can of course easily be done via the new 
HT_IS_FULLY_PACKED macro. We can improve this code for a large amount of arrays 
with the following simple snippet for 
https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L38 :

if (HT_IS_FULLY_PACKED(myht))
  return PHP_JSON_OUTPUT_ARRAY;

I'll be happy to make an effort to screen the entire code base in search for 
more cases where this could be useful once this is picked up by a lead core 
developer (maybe Xinchen?) who is willing to commit something on the lines of 
the above.

Any thoughts?

Benjamin

--

Bejamin Coutu
ben.co...@zeyos.com

ZeyOS, Inc.
http://www.zeyos.com

[PHP-DEV] Re: Constants for better double edge case handling

[Andrea Faulds]

Hi Anatol,

Anatol Belski wrote:

Producing INF. There's currently no explicit way to produce INF and NAN,
whereby NAN is gettable with sqrt(-1).

echo PHP_DBL_MAX*PHP_DBL_MAX, " ", -PHP_DBL_MAX*PHP_DBL_MAX;
INF -INF


I'm not sure I understand this use-case. We already have the INF and NAN 
constants for obtaining those values, and the standard IEEE 754 
operations which produce these values are implemented (1/0 for INF, 0/0 
for NAN, etc.)


--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Re: Fixing insane session_start() behaviors

[Yasuo Ohgaki]

Hi Stas,

On Wed, Oct 19, 2016 at 8:57 PM, Yasuo Ohgaki  wrote:
> Only valid use case is
>
>  ob_start();
> session_start();
> session_set_cache_limiter('public'); // <== Call this between
> session_start() and session_regenerate_id()
> session_regenerate_id();
> ?>
>
> Other than this, all calls after session_start() is invalid. Valid use
> case is very limited and unlikely. If users have to change cache
> limiter, they can session_commit(), then session_start(). So I would
> like to keep as it is now.

I thought php_session_reset_id() sends all headers, but it sends only
session ID cookie header. So current code is good. Sorry for
confusion.

Regards,

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

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

Re: [PHP-DEV] Re: Fixing insane session_start() behaviors

[Yasuo Ohgaki]

Hi Davey,

On Wed, Oct 19, 2016 at 6:06 PM, Davey Shafik  wrote:
> Yasuo, assuming "partial fix" doesn't mean "broken fix" but instead "it
> doesn't do everything I planned" then I do not want this in 7.1. As others
> have pointed out, it's not a small change and sessions are a fundamental
> part of PHP — we are simply too far into the release cycle to include this.
>
> Please target 7.2/master.

OK. I'll merge this to master.

Partial fix is done so that it does not break internal API signatures.
It's fixed as plain bug fix. PHP 7.1's session_start() sets a little
better session status and 'FALSE' than older PHP, but it's far from
correct/reliable. I'll update UPGRADING comment.

Regards,

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

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

Re: [PHP-DEV] Re: Fixing insane session_start() behaviors

[Yasuo Ohgaki]

Hi Stas,

On Wed, Oct 19, 2016 at 3:08 PM, Stanislav Malyshev  wrote:
>> I pushed patch fixes number of nonsense/inconsistent session function
>> behaviors. The additional patch is pushed so that it's easy to cherry
>> pick minimum fixes. The last push is the additional fixes.
>
> These changes look like a reasonable cleanup. I'm not a big fan of
> zend_parse_parameters_none additions, since I don't see any useful
> function for them, but they don't hurt either. I left some notes on the
> patch though, please look there.
>
> I'm not sure about 7.1 - while I don't see anything that would break any
> reasonable code, except issues noted on the pull, the patch is pretty
> big and I might have missed something. I guess it's for RM to decide. No
> objection for 7.2.
>
> I notice that most test changes deal with scenarios that were covered
> before, are there tests that test the new things - the scenarios for
> which handling has changed? I couldn't find tests for some cases, like
> INI modification, would be nice to add them.
>
> Also, a reminder that you'd have to update all the documentation in the
> manual to reflect the change in the return values. And UPGRADING too.

Thank you.
I replied to your comments.

There is one debatable comment regarding session_cache_limiter().
We may delay error check at 'headers sent'. I suppose almost all usage
is misuse.

Only valid use case is



Other than this, all calls after session_start() is invalid. Valid use
case is very limited and unlikely. If users have to change cache
limiter, they can session_commit(), then session_start(). So I would
like to keep as it is now.

Regards,

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

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

RE: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

[Anatol Belski]

Hi Yasuo,

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohg...@ohgaki.net]
> Sent: Wednesday, October 19, 2016 2:35 AM
> To: Anatol Belski 
> Cc: Joe Watkins ; Niklas Keller ;
> Leigh ; PHP Internals 
> Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness
> 

> I think you and Joe could not follow the discussion. It's okay, reading them 
> all is
> waste of your time. I read all, but I'm not sure if I understand/remember all 
> of
> them well.
> 
We all have own things, yes. I've checked the early messages in this thread, 
and checked the latest now, and checked the patch as well. Calling it waste of 
time is not correct. I just happen to manage 7.0, so I have to jump into such 
situations. My task in such case is to moderate the process, to hopefully help 
to reach the a common decision.

> IMHO Oppositions for the patch is based on _wrong_ assumption that "new
> uniqid() causes common enough errors to be an issue". This wrong assumption is
> the reason why my commit became an issue, I presume.
> 
> Could you reconsider decision based on _wrong_ assumption?
> 
I don't think the opinions should be ignored. The sense of discussion is to 
clear out all possible issues and to improve the approach, not doing as 
assumptions ping-pong. The actual issue is, that it was commited while the 
concerns was not cleared out and the discussion didn't reach a common opinion. 
Also, where Davey asked you already at some early stage to go by an RFC, the 
merge into 7.0 was somewhat sudden.

> 
> P.S. I'm a bit tired of uniqid() discussion because I expected this is easy 
> one.
> This - unique id (time stamp) + entropy (timestamp based entropy) - is 
> obviously
> wrong for today's PHP.
Speaking about broken - there's always some acceptance criteria. Like you might 
know in physics, uncertainty analysis, some result is always given with +/- 
inaccuracy. It is applicable to anything measurable, thus to uniqid() as well. 
What you say, is that the acceptance criteria is now changed, and the result 
needs to be more accurate. From the other side, there are voices telling the 
result is still acceptable. 

> I won't have time to write RFC for this, probably. I have many other things 
> that I
> would like to improve, like session error status handling improvement that I
> recently proposed.
> 
I see. It's a pity you won't have time to write an RFC. I see one already in 
place on the wiki though. I see also your several other patches hanging on 
gihtub. IMHO it is a real waste of time to abandon the work you've done, 
without really pulling it through. With uniqid(), maybe it'd be even the right 
decision to return to your original RFC, or just to reduce it to comply with 
the simple patch variant. I'm sure, that no one wants to lose the good 
contributions, even though it might take some effort to reach the common ground 
sometimes.

Regards

Anatol




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

Re: [PHP-DEV] Exploit fully packed array/hash property

[Dmitry Stogov]

Hi Benjamin,


I think this is great idea!

Let me check that can we get from this, and if we may add this into PHP-7.1 (it 
may be to late).


Thanks. Dmitry.


From: Benjamin Coutu 
Sent: Wednesday, October 19, 2016 1:45:00 PM
To: Xinchen Hui; Dmitry Stogov; Nikita Popov
Cc: PHP Internals
Subject: [PHP-DEV] Exploit fully packed array/hash property

Hello everyone,

I've identified a few more array/hash use cases where it might make sense to 
introduce special short circuit logic for packed arrays.

Specifically, there is an additional property of certain packed arrays (apart 
from being packed obviously) that we can utilize: A packed array with nNumUsed 
equal to nNumOfElements must be consecutively indexed from zero onward without 
any gaps (no IS_UNDEF). Let's call this special pure form of a packed array a 
"fully packed array".

Earlier I have posted on how this convenient property could speed things up for 
array_slice, even if preserved_keys=true (for the offset=0 case), see 
https://marc.info/?l=php-internals=147048569215717=2

I therefore propose to introduce the following two new macros in 
/Zend/zend_types.h in order to make it easier for developers to introduce 
special packed (or fully packed) array logic:

#define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
#define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed == 
(ht)->nNumOfElements)

With this we can easily speed things up (and more importantly preserve the 
packed array characteristics) for the common case of array_slice($packed_array, 
$offset=0, $length, $preserved_keys=true) by using the follwing snippet for 
https://github.com/php/php-src/blob/master/ext/standard/array.c#L2906 :

if (preserve_keys ? (offset == 0 && HT_IS_FULLY_PACKED(Z_ARRVAL_P(input))) : 
HT_IS_PACKED(Z_ARRVAL_P(input)))
  ... ZEND_HASH_FILL_PACKED ...

Another example where this could come in handy involves the encoding of JSON. 
For every array that it encodes, json_encode must first detemine wheter the 
array contains string keys or is not consecutively indexed, so that it can 
decide wheter to use a JSON object or a plain JSON array. That is accomplished 
through php_json_determine_array_type in /ext/json/json_encoder.c. That code 
currently has to iterate through the array until it finds a string key or a 
non-consecutive index (which in the worst case would mean iterating through the 
entire array).

Now, for fully packed arrays we can short circuit things and jump directly to 
the conclusion of it being a real plain old array, if it is packed and we can 
prove it has no gaps. That can of course easily be done via the new 
HT_IS_FULLY_PACKED macro. We can improve this code for a large amount of arrays 
with the following simple snippet for 
https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L38 :

if (HT_IS_FULLY_PACKED(myht))
  return PHP_JSON_OUTPUT_ARRAY;

I'll be happy to make an effort to screen the entire code base in search for 
more cases where this could be useful once this is picked up by a lead core 
developer (maybe Xinchen?) who is willing to commit something on the lines of 
the above.

Any thoughts?

Benjamin

--

Bejamin Coutu
ben.co...@zeyos.com

ZeyOS, Inc.
http://www.zeyos.com

Re: [PHP-DEV] PHP-7.1.0RC4

[Davey Shafik]

Thanks Joe!

- Davey

On Wed, Oct 19, 2016 at 3:48 AM, Joe Watkins  wrote:

> Morning internals, QA folks,
>
> I would like to announce the availability of PHP-7.1.0RC4.
>
> Downloads: http://downloads.php.net/~krakjoe/
>
> php-7.1.0RC4.tar.bz2
> SHA256 hash:
> ed2ef6dec04d1f8745b6212c55684cfd1350fad28db4c659ff99e9c6d16d3f36
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJYB0z4AAoJEJZAoYTDlTxVvbsP/RM9VO8U7LABB4F3lWbmo0wW
> riCmURs82XUK4x+C+Bq16vpro+cJGISSCaD5YZpWd53DONm0JaB6jWKdw/2aQfVc
> Whjd9D+WYL4JgTfJNQgOcIFfTx0fpQnVe0OwT5DqwPrlzHRt3Ek6zeBkXtXtzJM/
> eibyFtkK2E7c8NojBgUb64PwHu8e+EjGiMg5m0eiqIZc9Ogg/Fq11/piLkPy3U8A
> J+DfoAJhArsNfTWpv87pJhg377yQkapxqYEfpFKGGS+/qA29hqYEwnNnEoXUyuRF
> vfs5l56XWexcmOQQA8k9XdTs87+pMoC2GsgtCWxU9HGu/bqseHoeylsXAAz84veL
> ePJsZyyf+MK/ksOEBlaMrjct3MEDS7wMKWk2Oqym5po/sdnA+XiKb0l1UNkNTbcp
> HqXL9U94QV/NsRDlmboQ/NilYqr3k4YoqMMWYJdqIsmYm5ldTQem+rvuUno8nx8a
> byYvdUXXrbbM+hmKX8gGqV0ERfRLUU44xByTqpftJPVTsaisdkTY1hzRwJKTkZOI
> gzm9czciPJOUdVuMJEt+tw+wyI6IGcVMFwjVk6Nf2voTtP1t5b9NXR6u/9dMDgJm
> bfqbV4ffIMBG7Rf9ggELmcBeK4brfBFSwJYZuoQl7QJprYH/jTbSnkSQ/lkOQDLv
> xG9ppUCWmSViKJUzHYLw
> =txIc
> -END PGP SIGNATURE-
>
>
> php-7.1.0RC4.tar.gz
> SHA256 hash:
> 8701d826d210abaa0d54d9a8344d14f00f1fb34d918b14e61f4fdd1b19226c46
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJYB0z8AAoJEJZAoYTDlTxVcZUP/3Ot1CVledtqVcsLCLrPnWBj
> KxPH999OJy7gwuXQsCHF5QfwZGU1lrc/y9wAIHkaB26FANnkOujhHV6tcMqc03N0
> tI26YklI0bZJJ0FDGgh+GH5vQL6Tx5Dxy1KfMB/2BTi0+rjwS5L1qfN8fX4DhWjQ
> 1TeMkeM+tAkjIlPGoUWzvqzo/n21ANnHwLspQxQgG/+lW8b61UBD00jtXY9XByNS
> pCG8q1ebKb+jBMa8fuPdRsxbDOsdqQzPhwIehO6sWy8P+NpdXjwR7+UmO5Wh2EZw
> jyiv4Xll4z3rj6X2AVdeVirUv464HQpBFdqZLVu3L4RMx5o6UbLep1nw5DQjpWoZ
> PPQzWcGr5DcuTG4d399wC93ti04tmksjOfrLazdAVcJ8zjXpJYYuFlg3kbJnMpqw
> a+6pkPtMQIsbAu6Kgc4e+fQmsEIlwjCFhRAA7WDPF+nxuHnun1QnrpsPAZGeQqau
> PMj419dxk26NmVKedlofBdn+X9GEJItIaVyHwy1x80qo+yYtJaokzMdnMg6C+KwF
> /Zxi5VYzdSAnZX3tSs5BTQ3HzzFC5S3P6UwD8dDZA/ADETxo2vhJyANMFuvGwAH/
> uTGjqfi30q3naDFwBbKUeNinLCIR5B8D1ryJy0F1kOIB8rpclFS9UuplCZQ5ie5M
> wbP2tQWvhFfuyXoPvfEL
> =8IdV
> -END PGP SIGNATURE-
>
>
> php-7.1.0RC4.tar.xz
> SHA256 hash:
> aa06af4cd4674b4a57969d39566497d700c291f433209f8c83b75ffc1128d258
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJYB00AAAoJEJZAoYTDlTxVcW0P/0FH00FnGMvIUBfkmyPVu6Lh
> KeeW9G2Zudy1IXjmjtYJLeQn0ese0aHEHhBgSF83Ukje00QQgI/MGVBF4T05zS8M
> agLbqzgHwaKEdZpPBpSrhD8UWJN47F8evti5NtyZmq6VGdNEEwyNgf82sjIn7Hxy
> gYJAIRxi7DbGSfff0QQndVl1hkFsvDtjFRHxbymloTwb5edbntYSQxGJJWSg6SXj
> TvD85dEI1VP8zznq5CTQFrJVF+YdU7FUIq9Gs4ATKIFqHEzbyRDWC34OF2Au+shW
> eboi0ELDR3G4Jf0z1/hBb8i+ovhSOWSmGC/BtESGqF2QGqeoncZwGNGtAoecVZHF
> Fok+XVIxSwGFG2Ang7F7rWGCWpqS9PEeQQgrDfuSFER462Ke5tBiFDHvdc2Mm+tZ
> dXQsE80TcWxOTFaDGNVt4exwkMW+pIqZPRhr+L4H5XeDsgJWgmHF4OWyZ8h2MzoD
> 0Qy0Q1vkuV3f52dR+Sc2ySgZ+3+wTOy99omxi9sMcWJDf71EGKVyasBbWXxtd1NK
> KHOfdWSTZSeEgG1doSEQVuyYv41m0R4fPE4+w1SIxC9bfmzRtwn71cHckco6Qaua
> hv1y6EnbhS2fBjWRIsKrS8HtWu30+IGlBdSflmRnXPH/pzpEB8CEqzPvd//fhubo
> Gxnx7odid2/98tvjh3Vg
> =YB0l
> -END PGP SIGNATURE-
>
> Please see NEWS and UPGRADING for recent changes.
>
> Sorry about the delay.
>
> Cheers
> Joe
>

[PHP-DEV] PHP-7.1.0RC4

[Joe Watkins]

Morning internals, QA folks,

I would like to announce the availability of PHP-7.1.0RC4.

Downloads: http://downloads.php.net/~krakjoe/

php-7.1.0RC4.tar.bz2
SHA256 hash:
ed2ef6dec04d1f8745b6212c55684cfd1350fad28db4c659ff99e9c6d16d3f36
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJYB0z4AAoJEJZAoYTDlTxVvbsP/RM9VO8U7LABB4F3lWbmo0wW
riCmURs82XUK4x+C+Bq16vpro+cJGISSCaD5YZpWd53DONm0JaB6jWKdw/2aQfVc
Whjd9D+WYL4JgTfJNQgOcIFfTx0fpQnVe0OwT5DqwPrlzHRt3Ek6zeBkXtXtzJM/
eibyFtkK2E7c8NojBgUb64PwHu8e+EjGiMg5m0eiqIZc9Ogg/Fq11/piLkPy3U8A
J+DfoAJhArsNfTWpv87pJhg377yQkapxqYEfpFKGGS+/qA29hqYEwnNnEoXUyuRF
vfs5l56XWexcmOQQA8k9XdTs87+pMoC2GsgtCWxU9HGu/bqseHoeylsXAAz84veL
ePJsZyyf+MK/ksOEBlaMrjct3MEDS7wMKWk2Oqym5po/sdnA+XiKb0l1UNkNTbcp
HqXL9U94QV/NsRDlmboQ/NilYqr3k4YoqMMWYJdqIsmYm5ldTQem+rvuUno8nx8a
byYvdUXXrbbM+hmKX8gGqV0ERfRLUU44xByTqpftJPVTsaisdkTY1hzRwJKTkZOI
gzm9czciPJOUdVuMJEt+tw+wyI6IGcVMFwjVk6Nf2voTtP1t5b9NXR6u/9dMDgJm
bfqbV4ffIMBG7Rf9ggELmcBeK4brfBFSwJYZuoQl7QJprYH/jTbSnkSQ/lkOQDLv
xG9ppUCWmSViKJUzHYLw
=txIc
-END PGP SIGNATURE-


php-7.1.0RC4.tar.gz
SHA256 hash:
8701d826d210abaa0d54d9a8344d14f00f1fb34d918b14e61f4fdd1b19226c46
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJYB0z8AAoJEJZAoYTDlTxVcZUP/3Ot1CVledtqVcsLCLrPnWBj
KxPH999OJy7gwuXQsCHF5QfwZGU1lrc/y9wAIHkaB26FANnkOujhHV6tcMqc03N0
tI26YklI0bZJJ0FDGgh+GH5vQL6Tx5Dxy1KfMB/2BTi0+rjwS5L1qfN8fX4DhWjQ
1TeMkeM+tAkjIlPGoUWzvqzo/n21ANnHwLspQxQgG/+lW8b61UBD00jtXY9XByNS
pCG8q1ebKb+jBMa8fuPdRsxbDOsdqQzPhwIehO6sWy8P+NpdXjwR7+UmO5Wh2EZw
jyiv4Xll4z3rj6X2AVdeVirUv464HQpBFdqZLVu3L4RMx5o6UbLep1nw5DQjpWoZ
PPQzWcGr5DcuTG4d399wC93ti04tmksjOfrLazdAVcJ8zjXpJYYuFlg3kbJnMpqw
a+6pkPtMQIsbAu6Kgc4e+fQmsEIlwjCFhRAA7WDPF+nxuHnun1QnrpsPAZGeQqau
PMj419dxk26NmVKedlofBdn+X9GEJItIaVyHwy1x80qo+yYtJaokzMdnMg6C+KwF
/Zxi5VYzdSAnZX3tSs5BTQ3HzzFC5S3P6UwD8dDZA/ADETxo2vhJyANMFuvGwAH/
uTGjqfi30q3naDFwBbKUeNinLCIR5B8D1ryJy0F1kOIB8rpclFS9UuplCZQ5ie5M
wbP2tQWvhFfuyXoPvfEL
=8IdV
-END PGP SIGNATURE-


php-7.1.0RC4.tar.xz
SHA256 hash:
aa06af4cd4674b4a57969d39566497d700c291f433209f8c83b75ffc1128d258
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJYB00AAAoJEJZAoYTDlTxVcW0P/0FH00FnGMvIUBfkmyPVu6Lh
KeeW9G2Zudy1IXjmjtYJLeQn0ese0aHEHhBgSF83Ukje00QQgI/MGVBF4T05zS8M
agLbqzgHwaKEdZpPBpSrhD8UWJN47F8evti5NtyZmq6VGdNEEwyNgf82sjIn7Hxy
gYJAIRxi7DbGSfff0QQndVl1hkFsvDtjFRHxbymloTwb5edbntYSQxGJJWSg6SXj
TvD85dEI1VP8zznq5CTQFrJVF+YdU7FUIq9Gs4ATKIFqHEzbyRDWC34OF2Au+shW
eboi0ELDR3G4Jf0z1/hBb8i+ovhSOWSmGC/BtESGqF2QGqeoncZwGNGtAoecVZHF
Fok+XVIxSwGFG2Ang7F7rWGCWpqS9PEeQQgrDfuSFER462Ke5tBiFDHvdc2Mm+tZ
dXQsE80TcWxOTFaDGNVt4exwkMW+pIqZPRhr+L4H5XeDsgJWgmHF4OWyZ8h2MzoD
0Qy0Q1vkuV3f52dR+Sc2ySgZ+3+wTOy99omxi9sMcWJDf71EGKVyasBbWXxtd1NK
KHOfdWSTZSeEgG1doSEQVuyYv41m0R4fPE4+w1SIxC9bfmzRtwn71cHckco6Qaua
hv1y6EnbhS2fBjWRIsKrS8HtWu30+IGlBdSflmRnXPH/pzpEB8CEqzPvd//fhubo
Gxnx7odid2/98tvjh3Vg
=YB0l
-END PGP SIGNATURE-

Please see NEWS and UPGRADING for recent changes.

Sorry about the delay.

Cheers
Joe

[PHP-DEV] Exploit fully packed array/hash property

[Benjamin Coutu]

Hello everyone,

I've identified a few more array/hash use cases where it might make sense to 
introduce special short circuit logic for packed arrays.

Specifically, there is an additional property of certain packed arrays (apart 
from being packed obviously) that we can utilize: A packed array with nNumUsed 
equal to nNumOfElements must be consecutively indexed from zero onward without 
any gaps (no IS_UNDEF). Let's call this special pure form of a packed array a 
"fully packed array".

Earlier I have posted on how this convenient property could speed things up for 
array_slice, even if preserved_keys=true (for the offset=0 case), see 
https://marc.info/?l=php-internals=147048569215717=2

I therefore propose to introduce the following two new macros in 
/Zend/zend_types.h in order to make it easier for developers to introduce 
special packed (or fully packed) array logic:

#define HT_IS_PACKED(ht) ((ht)->u.flags & HASH_FLAG_PACKED)
#define HT_IS_FULLY_PACKED(ht) (HT_IS_PACKED(HT) && (ht)->nNumUsed == 
(ht)->nNumOfElements)

With this we can easily speed things up (and more importantly preserve the 
packed array characteristics) for the common case of array_slice($packed_array, 
$offset=0, $length, $preserved_keys=true) by using the follwing snippet for 
https://github.com/php/php-src/blob/master/ext/standard/array.c#L2906 :

if (preserve_keys ? (offset == 0 && HT_IS_FULLY_PACKED(Z_ARRVAL_P(input))) : 
HT_IS_PACKED(Z_ARRVAL_P(input)))
  ... ZEND_HASH_FILL_PACKED ...
  
Another example where this could come in handy involves the encoding of JSON. 
For every array that it encodes, json_encode must first detemine wheter the 
array contains string keys or is not consecutively indexed, so that it can 
decide wheter to use a JSON object or a plain JSON array. That is accomplished 
through php_json_determine_array_type in /ext/json/json_encoder.c. That code 
currently has to iterate through the array until it finds a string key or a 
non-consecutive index (which in the worst case would mean iterating through the 
entire array).

Now, for fully packed arrays we can short circuit things and jump directly to 
the conclusion of it being a real plain old array, if it is packed and we can 
prove it has no gaps. That can of course easily be done via the new 
HT_IS_FULLY_PACKED macro. We can improve this code for a large amount of arrays 
with the following simple snippet for 
https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L38 :

if (HT_IS_FULLY_PACKED(myht))
  return PHP_JSON_OUTPUT_ARRAY;

I'll be happy to make an effort to screen the entire code base in search for 
more cases where this could be useful once this is picked up by a lead core 
developer (maybe Xinchen?) who is willing to commit something on the lines of 
the above.

Any thoughts?

Benjamin

-- 

Bejamin Coutu
ben.co...@zeyos.com

ZeyOS, Inc.
http://www.zeyos.com


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

Re: [PHP-DEV] Re: Fixing insane session_start() behaviors

[Davey Shafik]

On Tue, Oct 18, 2016 at 11:08 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > I pushed patch fixes number of nonsense/inconsistent session function
> > behaviors. The additional patch is pushed so that it's easy to cherry
> > pick minimum fixes. The last push is the additional fixes.
>
> These changes look like a reasonable cleanup. I'm not a big fan of
> zend_parse_parameters_none additions, since I don't see any useful
> function for them, but they don't hurt either. I left some notes on the
> patch though, please look there.
>
> I'm not sure about 7.1 - while I don't see anything that would break any
> reasonable code, except issues noted on the pull, the patch is pretty
> big and I might have missed something. I guess it's for RM to decide. No
> objection for 7.2.
>
> I notice that most test changes deal with scenarios that were covered
> before, are there tests that test the new things - the scenarios for
> which handling has changed? I couldn't find tests for some cases, like
> INI modification, would be nice to add them.
>
> Also, a reminder that you'd have to update all the documentation in the
> manual to reflect the change in the return values. And UPGRADING too.


> I was planning to fix session_start() behaviors by PHP 7.1, but I
> forgot to do this completely. Partial fix is merged currently.

Yasuo, assuming "partial fix" doesn't mean "broken fix" but instead "it
doesn't do everything I planned" then I do not want this in 7.1. As others
have pointed out, it's not a small change and sessions are a fundamental
part of PHP — we are simply too far into the release cycle to include this.

Please target 7.2/master.

Thanks,

- Davey

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

[Nikita Popov]

On Wed, Oct 19, 2016 at 1:48 AM, Daniel Morris 
wrote:

> On Tue, 18 Oct 2016, at 09:22 AM, Nikita Popov wrote:
> > On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:
> >
> > > As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
>
> Why do we need GMP when we have BCMath?


Because GMP implements big integer arithmetic, while BCMath implements big
decimal arithmetic.


> GMP is faster (from what I've
> seen so far from various tests and blog posts) – whilst they do similar
> ops, they are chosen for specific reasons, all this does is expose the
> existing interfaces for arbitrary precision arithmetic made available
> with the OpenSSL layer, and I think anyone implementing them would want
> the API there, it requires minimal maintenance. Sara, I think the best
> route is too match the method names within OpenSSL, it will avoid some
> initial confusion, unless people want to change libraries, but I think
> that is probably less likely.
>

What are the specific reasons for choosing OpenSSL Bignums over GMP,
outside of extension availability (which is totally a path I don't want us
to go down -- see also recent attempts to duplicate ext/mbstring into
ext/standard)? Are there any particular properties of the openssl
implementation that are beneficial for certain applications?

Nikita

Re: [PHP-DEV] Re: Fixing insane session_start() behaviors

[Stanislav Malyshev]

Hi!

> I pushed patch fixes number of nonsense/inconsistent session function
> behaviors. The additional patch is pushed so that it's easy to cherry
> pick minimum fixes. The last push is the additional fixes.

These changes look like a reasonable cleanup. I'm not a big fan of
zend_parse_parameters_none additions, since I don't see any useful
function for them, but they don't hurt either. I left some notes on the
patch though, please look there.

I'm not sure about 7.1 - while I don't see anything that would break any
reasonable code, except issues noted on the pull, the patch is pretty
big and I might have missed something. I guess it's for RM to decide. No
objection for 7.2.

I notice that most test changes deal with scenarios that were covered
before, are there tests that test the new things - the scenarios for
which handling has changed? I couldn't find tests for some cases, like
INI modification, would be nice to add them.

Also, a reminder that you'd have to update all the documentation in the
manual to reflect the change in the return values. And UPGRADING too.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: header() removes all header of the same name.

[Yasuo Ohgaki]

Hi all,

On Wed, Oct 19, 2016 at 1:34 PM, Yasuo Ohgaki  wrote:
>
> On Wed, Oct 19, 2016 at 12:18 PM, Stephen Reay  
> wrote:
>> I still have an issue with that. I believe the correct behaviour here is 
>> (assuming the `replace` argument to header() is honoured) what you’re 
>> seeing. Yes, it might be *unexpected* for new users, but its also *expected* 
>> by millions of current users/projects.
>>
>> I would suggest perhaps a warning on the header() docs page, and perhaps an 
>> example to avoid the issue on the Session handling page.
>>
>> Leaving it as-is, with improved docs means all functionality is *possible* 
>> with the right arguments.
>>
>> Changing to your proposal means advanced use-cases are *impossible* with any 
>> arguments.
>>
>>
>> I realise you’re trying to remove WTF cases, but I don’t think removing 
>> advanced capabilities is the way to do that.
>
> Yes. Even framework developer(?) seems to have current behavior.
>
> In general, users shouldn't touch session ID. In case of user really
> want to modify session ID cookie, following could be done.
>
>  ob_start();
> session_start();
> header_remove('Set-Cookie');
> header('Set-Cookie: PHPSESSID= something');
> ?>
>
> Make header_remove() able to delete 'Set-Cookie' header. (Current behavior)
> Make header() able to send 'Set-Cookie' header. (Current behavior, but
> not remove session ID cookie)
>
> This allows users to send arbitrary session ID cookie when it is
> needed really needed, while avoiding accidental session ID cookie
> removal.
>
> What do you think?

Another idea for session ID cookie and Set-Cookie header protection.

Since we have setcookie() function, how about to have cookie
dedicated functions for cookie header manipulation.

I'm about to create new feature request as follows:
-
Protect session ID and other cookies from header(), header_remove()
-
header() removes any previously defined headers.
header('Set-Cookie: something') / header_remove() deletes session ID
and other Set-Cookie headers. Cookies should be protected from
header()/header_remove().

Instead, create new cookie functions

cookie_set() - Set cookie header (setcookie() alias)
cookie_set_raw() - Set cookie header (setrawcookie alias)
cookie_custom() - Set cookie with custom style.
   (The same as header(sprintf('Set-Cookie:
%s', something));
cookie_remove() - Remove all cookie header. $name parameter is cookie
name to be deleted.

Protect Set-Cookie headers from header() and header_remove()
--

This implementation is cleaner because core to session
dependency is not required. It is also good to have naming standard
confirming cookie function names. i.e. Cookie functions should be
named cookie_*() according to CODING_STANDARDS.

Regards,

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

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