[PHP-DEV] Re: Zend JIT Open Sourced
Hey: On Fri, Feb 27, 2015 at 8:10 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instruction. Don't merge it with master. It may work today but will stop working tomrrow. Disclaimers: - It's an experiment, and is not in any way ready for anything. In the future we may try to implement JIT quite different from this PoC. - I'm not planning to invest into it in the near future. (PHP-7 takes all my time) Consider it available for academic purposes only at this point. Great, too many threads these days, I almost miss this mail :) the mail problem here is we can not get real performance improvement in reallife apps. opensource this, could maybe get more ideas on how to improve it. (except the icachemiss, dcachemiss we already knew). welcome to play with it, and give some thoughts :) thanks Enjoy! Thanks. Dmitry. -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi all,
On Sat, Feb 28, 2015 at 11:37 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing allow_url_include INI option. [1]
During Script only include RFC[2] discussion, stream wrapper issue is
raised.
I was thinking this issue as a separate issue, but it seems others are
not.
I'm not convinced by the argument that because phar://blah looks like a
URL, allowing it makes allow_url_include broken. Perhaps it would be better
named allow_remote_include, but it corresponds to masking out your
PHP_STREAM_REMOTE flag further down, which is the more important
protection. If you want to be able to disable phar:// access, you could add
something like allow_local_stream_include for that case without breaking BC.
allow_local_stream_include is one possible solution. It has the same
problem with allow_url_include.
Since allor_url_include is global INI, it applies to child scripts. e.g.
A.php
-
?php
ini_set('allow_url_include', 'On');
include('B.php');
-
B.php
-
?php
include($_GET['var']); // Not only local script execution vulnerable, but
also remote script execution is possible because allow_url_include=On
here.
-
We need to control these flags more precisely. That's the reason why I
proposed 2nd parameter for include.
If flags are globals, we cannot control them as it should.
URL and URI is the same for most users, I think. (It differs, but their
usage is mostly the same) Not
many users expect to work something like
include('new_wrapper://some_file_with_special_content/some_how_php_script_is_accecible_suddenly');
Attackers can write malicious user stream wrapper as back door. Then
upload attack file and takeover
server. The wrapper will be hard to distinguish if it's legitimate or not.
Attack file can be any kind of
format. It's impossible to detect as malicious file. URL formed script
(stream wrapper) is very flexible/handy/
hard to be detected tool for attackers.
Remote resource is extremely danger. Local resource is very dangerous
also. Current phar:// wrapper
implementation spoils file extension and .. (double dot) protection that
is deployed by many PHP codes
already. User wrapper seems allowed for include(), so malicious user
wrapper can help attackers to
exploit PHP servers.
I'm also not at all clear what you mean by caller and callee
responsibilities; surely the difference is just between a global option
(ini_set()) and a local one (extra argument)? And in what way does Option
#2 require more changes than Option #1, since they both require the
argument to be present whenever a stream wrapper is used?
First question is answered in previous comment. INI cannot control flags
precisely...
Option #1 is simple string comparison for filename is passed. It does not
care what's the filter at all nor even filter name is valid or not. 2nd
parameter is
used to make sure filename passed to include() is user's intension. e.g.
-
// somewhere deep in code
$module_name = substr($_GET['module'], -4, 4) === '.php' ?
$_GET['module'] : ''; // Do not care to much, we have safe .php files.
// somewhere far from above code
include($module_name); // phar://evil_phar/evil_script.php can be executed.
-
With this RFC, if 2nd parameter is omitted
--
include($module_name); // E_RROR, URL formed include(stream wrapper) is
not allowed.
--
to use phar. User must be explicit.
-
include($module_name, 'phar://');
-
Option #2 will be much more complex than Option #1, since it introduces
types of wrapper, force users to have class method return wrapper type and
pass flags around functions to handle wrapper types correctly. There may be
more.
I do think local options are better than global ini settings in many
cases, but include/require/etc are statements, not functions, so giving
them extra arguments is awkward - some of your examples are wrong in this
regard:
// Redundant brackets make this look like a function, but it's not:
include('phar://phar_file/script.php');
// I can add as many as I like, the parser is just resolving them to a
single string expression:
include'phar://phar_file/script.php';
// This is the actual syntax:
include'phar://phar_file/script.php';
// Implying this for arguments:
include'phar://phar_file/script.php', 'phar://';
// You could explicitly allow a function form of the statements, so you
could parse this:
include(('phar://phar_file/' . $script_name), 'phar://');
// But then you've got a subtle BC break, because the interpretation of
this changes:
include ($foo) . ('.php');
I used include('phar://phar_file/script.php'), but it can be include
'phar://phar_file/script.php'.
I'm using () since it seemed harder to distinguish parameters and other
text as we can
use () for include/require now.
I
Re: [PHP-DEV] [RFC] UString
Morning internals, This is just a quick note to announce my intention to ready this RFC for voting next week. I know I'm a little late maybe, I was real sick most of last week, so couldn't do anything useful. A couple of us intend to fix outstanding issues on github and those raised here, tidy the RFC and open the vote for 7. I would ask anyone interested to scan through this thread and announce concerns that are not mentioned asap. Cheers Joe On Fri, Oct 24, 2014 at 3:01 PM, Chris Wright daveran...@php.net wrote: On 24 October 2014 07:03, Joe Watkins pthre...@pthreads.org wrote: On Thu, 2014-10-23 at 12:54 -0700, Stas Malyshev wrote: Hi! P.S. u() is a bad name, will break lots of code, i.e. Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's safe. /me cringes ... I wonder how much of a problem it really is, usually when we say some function name is a problem is because of hundreds and hundreds of results on github. If it's a huge problem then we should rename it, if we have to dig around for a single project that's incompatible, or even a handful, then it's not really a problem. Cheers Joe I can see this being something relatively common. While I personally would never do it, there are a few reasons I can think of that people *might* do it: - Wrapper for creating u HTML output - urlencode() shortcut - (obviously) various unicode-related things Searching on codesearch [1] revealed (amongst a few other hits on the first page) another interesting use of it in the hhvm test suite [2]. It's difficult to search for this because all the available public search engines that I know of do fuzzy matching. Sorry. This sucks, because every other option we have for this is sucks. On the bright side, anything chosen could always be aliased at the top of the file: use function __u as u; This also sucks, but it sucks a little bit less because the collisions are avoided - or at least, avoided in such a way that the onus is on the user - and one can still have the sane name. First-class support at the syntax level (presumably $foo = uunicode string since we already have $foo = bbinary string) would IMO be better and (hopefully?) a long-term goal, but I am aware that it is - and probably should be - outside the scope of the current proposal. [1] https://searchcode.com/?q=function+u+lang%3Aphp [2] https://github.com/facebook/hhvm/blob/master/hphp/test/slow/ext_icu/uspoof.php#L13
Re: [PHP-DEV] [VOTE] Expectations
Morning Internals, As mentioned on the RFC, voting finished last night at midnight. The vote passed with a majority (50%+) in favour of custom exceptions, however ... When the patch was originally written assert (expect) was a language construct, and so the exception message wasn't constructed if the assertion passed. In the current patch, assert is still a function call, so to use custom assertions would cost considerably because the custom exception is a parameter (so, +1 object per assertion regardless of result). Because of this, we are not going to merge with custom exceptions enabled, they should not be crippling, another RFC will have to be written to deal with custom exceptions if that's something we want moving forward. Cheers Joe
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 28.02.2015 um 01:57 schrieb Larry Garfield: The RFC is currently in voting, so editing it directly is a no-no. A new, short RFC, please. (Exception implements Throwable, Error implements Throwable sounds good to me. Should we ask about SomeUserspaceClass implements Throwable, or will someone hit me for that?) I don't think Throwable should be implementable by userland classes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing allow_url_include INI option. [1]
During Script only include RFC[2] discussion, stream wrapper issue is
raised.
I was thinking this issue as a separate issue, but it seems others are
not.
I'm not convinced by the argument that because phar://blah looks like a
URL, allowing it makes allow_url_include broken. Perhaps it would be better
named allow_remote_include, but it corresponds to masking out your
PHP_STREAM_REMOTE flag further down, which is the more important
protection. If you want to be able to disable phar:// access, you could add
something like allow_local_stream_include for that case without breaking BC.
allow_local_stream_include is one possible solution. It has the same
problem with allow_url_include.
Since allor_url_include is global INI, it applies to child scripts. e.g.
A.php
-
?php
ini_set('allow_url_include', 'On');
include('B.php');
-
B.php
-
?php
include($_GET['var']); // Not only local script execution vulnerable, but
also remote script execution is possible because allow_url_include=On
here.
-
We need to control these flags more precisely. That's the reason why I
proposed 2nd parameter for include.
If flags are globals, we cannot control them as it should.
URL and URI is the same for most users, I think. (It differs, but their
usage is mostly the same) Not
many users expect to work something like
include('new_wrapper://some_file_with_special_content/some_how_php_script_is_accecible_suddenly');
Attackers can write malicious user stream wrapper as back door. Then upload
attack file and takeover
server. The wrapper will be hard to distinguish if it's legitimate or not.
Attack file can be any kind of
format. It's impossible to detect as malicious file. URL formed script
(stream wrapper) is very flexible/handy/
hard to be detected tool for attackers.
Remote resource is extremely danger. Local resource is very dangerous also.
Current phar:// wrapper
implementation spoils file extension and .. (double dot) protection that
is deployed by many PHP codes
already. User wrapper seems allowed for include(), so malicious user
wrapper can help attackers to
exploit PHP servers.
I'm also not at all clear what you mean by caller and callee
responsibilities; surely the difference is just between a global option
(ini_set()) and a local one (extra argument)? And in what way does Option
#2 require more changes than Option #1, since they both require the
argument to be present whenever a stream wrapper is used?
First question is answered in previous comment. INI cannot control flags
precisely...
Option #1 is simple string comparison for filename is passed. It does not
care what's the filter at all nor even filter name is valid or not. 2nd
parameter is
used to make sure filename passed to include() is user's intension. e.g.
-
// somewhere deep in code
$module_name = substr($_GET['module'], -4, 4) === '.php' ? $_GET['module']
: ''; // Do not care to much, we have safe .php files.
// somewhere far from above code
include($module_name); // phar://evil_phar/evil_script.php can be executed.
-
With this RFC, if 2nd parameter is omitted
--
include($module_name); // E_RROR, URL formed include(stream wrapper) is not
allowed.
--
to use phar. User must be explicit.
-
include($module_name, 'phar://');
-
Option #2 will be much more complex than Option #1, since it introduces
types of wrapper, force users to have class method return wrapper type and
pass flags around functions to handle wrapper types correctly. There may be
more.
I do think local options are better than global ini settings in many cases,
but include/require/etc are statements, not functions, so giving them extra
arguments is awkward - some of your examples are wrong in this regard:
// Redundant brackets make this look like a function, but it's not:
include('phar://phar_file/script.php');
// I can add as many as I like, the parser is just resolving them to a
single string expression:
include'phar://phar_file/script.php';
// This is the actual syntax:
include'phar://phar_file/script.php';
// Implying this for arguments:
include'phar://phar_file/script.php', 'phar://';
// You could explicitly allow a function form of the statements, so you
could parse this:
include(('phar://phar_file/' . $script_name), 'phar://');
// But then you've got a subtle BC break, because the interpretation of
this changes:
include ($foo) . ('.php');
I used include('phar://phar_file/script.php'), but it can be include
'phar://phar_file/script.php'.
I'm using () since it seemed harder to distinguish parameters and other
text as we can
use () for include/require now.
I have no intention to change current include/require syntax, except adding
2nd parameter.
Thank you for your feedback. I hope I explained well
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi! I have no intention to change current include/require syntax, except adding 2nd parameter. This is a bit misleading since include is not a function, so there's no 1st parameter. Instead, it's a syntax construct. Of course, syntax construct's grammar can be changed, though I'm not sure if that wouldn't lead to unexpected effects in the parser. But maybe not. Bigger issue is that if somebody is knowledgeable enough in security to go and change their code to use this option, why they aren't knowledgeable enough to fix their includes so this option is not required? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request and RFC
Thomas Gielfeldt wrote on 24/02/2015 16:17:
Hi internals.
I've made PR proposing a feature request: A new interface Sortable.
https://github.com/php/php-src/pull/1116
If possible, I would like to create and RFC describing this in more detail,
and perhaps get a voting on.
I think the reason this interface is proving hard to simplify is that
you're putting too much of the responsibility on the implementing
object. Most containers don't need or want to reimplement an entire
quicksort algorithm, or be responsible for tracking the various types of
comparison.
Ideally, you could start by writing an OO implementation of QuickSort
which takes as its input an abstract Collection instead of an array,
and look at what methods you end up wanting to call on that Collection.
That might end up rather complex in practice, though, because the
underlying data structures do make a difference to an efficient
implementation.
However, the types of sort differ primarily in the way values are
compared, so if the engine passed in an appropriate comparison callback,
the interface needs only one method:
public function sort(callable $comparison_callback, boolean $preserve_keys)
where $comparison_callback is:
function($l_key, $l_value, $r_key, $r_value): int
The only flag that the object might want to care about is whether to
preserve keys (asort, uasort, ksort, uksort), because it could allow
optimisations rather than reindexing after the sort has completed. For
everything else, it should just be repeatedly asking the engine which
of these two items should come first? By passing both keys and values,
ksort() can be implemented with the same callback signature, the only
disadvantage being that the user callbacks to usort() and uksort() would
need to be wrapped, with the engine basically emulating the following:
// For usort($object, $usort_callback)
$comparison_callback = function($l_key, $l_value, $r_key, $r_value) use
($usort_callback) { return $usort_callback($l_value, $r_value); };
// For ksort($object, $ksort_callback)
$comparison_callback = function($l_key, $l_value, $r_key, $r_value) use
($ksort_callback) { return $ksort_callback($l_key, $r_key); };
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
Hi, If we allow for trailing blanks, we'll allow the same set of chars that is already allowed for leading blanks. I say'blanks' and not 'whitespaces', because here is the list currently allowed as leading blank (with ascii values) : Space (32) , tab (9) , linefeed (10), carriage-return (13), vertical tab (11), and form feed (12). -Message d'origine- De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki Envoyé : vendredi 27 février 2015 11:25 À : Zeev Suraski Cc : Theodore Brown; internals@lists.php.net Objet : Re: [PHP-DEV] A different user perspective on scalar type declarations Hi Zeev, On Fri, Feb 27, 2015 at 2:48 AM, Zeev Suraski z...@zend.com wrote: You may have a point there. As Francois said, he was in favor of allowing leading and trailing spaces. I'll definitely reconsider. If we consider existing code, leading/trailing spaces may need to be allowed. Without considering compatibility issues, leading/trailing spaces should be validated or removed by user input validation/filter code in the first place. I think many users use $ for the end of string data for regex, but it includes newline. To be precise, \z should be used for both PCRE and mbregex. http://perldoc.perl.org/perlre.html Trailing newline is invalid. Leading/trailing spaces may be considered as the same invalid data to be strict. This is what I thought for this. I don't have strong opinion. 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] A different user perspective on scalar type declarations
On 27/02/15 13:12, François Laupretre wrote: If we allow for trailing blanks, we'll allow the same set of chars that is already allowed for leading blanks. I say'blanks' and not 'whitespaces', because here is the list currently allowed as leading blank (with ascii values) : Space (32) , tab (9) , linefeed (10), carriage-return (13), vertical tab (11), and form feed (12). Depending on the way a database is configured, one may be using char fields which are 'blank packed' fixed length, or varchar which would normally only include white space when it is actually added. It's not uncommon though to cast numeric fields to 'char' to create fixed length records and I would not like to say how many legacy systems still use that approach for building tables of data? -- 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] Coercive STH - some real world tests and updated RFC
Hi Christian, On Fri, Feb 27, 2015 at 5:15 PM, Christian Stoller stol...@leonex.de wrote: In this case FALSE is an expected result and it is intended. And as I said other languages are going the same way. Other languages are also doing something saner. It's not really an argument either way. Just because it makes more sense for you, it does not imply that it makes more sense for everybody. In my opinion it makes sense to return an error code if a function is called with invalid arguments. You probably haven't read the examples that I pasted. If you think that it makes sense to return an error code if the function is called with invalid arguments, it should be done consistently. The current behavior is just an absurdly inconsistent, it is really hard to find an argument in favor of it, other than the argument in favor of backward compatibility. Damien
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
This RFC trying to simpliy and cleanup the coercison rules, having two different conversion rules for NULL-scalar depending on userland or internal is counter-productive and bad. The behavior you describe as null being empty value is wide-spread in PHP userland code as well. I agree here with Benjamin. The thing I have wanted in user land for years is to be able to build a user land function that worked the way internal functions do in terms of type checking without having to build my own type checking system. Having internal functions convert null to a scalar and not having user land do the same creates an inconsistency. For example, sometimes you want to wrap/extend an internal function (you see it a lot with json* to do encoding checking). I can't reliably take the same input to my user land wrapper that I can send to the internal function. I would prefer to see the same rules apply to internal and user land. -- Brian. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, It's not a single request cycle. JIT integrated into opcache, it compiles php script(s) of first access and stores code in shared memory. On following requests precompiled code is executed directly from shared memory. - The first request may be extremely slow (few minutes) That sounds more along the lines of AOT like I did with Recki rather than a true JIT (which compiles when a function is called). Judging from the jit_init() function, it appears like you're compiling the entire codebase ahead of time. Is that correct? Right now it compiles script (php file) at once. So yes, our JIT uses some kind of AOT approach, but completely transparently for the rest of PHP. We also tried few different approaches to collect formation about hot functions and generate code only for them. Unfortunately, this didn't change the picture. Thanks. Dmitry. Anthony
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 27/02/15 14:15, Benjamin Eberlei wrote: Imho the problem is that the return values of php internal functions being string|false will lead to massive consecutive errors when passing this on to other internal functions. This is perhaps the crux of my objection to both types of 'error checking' ... OK the return should be an empty string rather than false, but certainly one does not want an exception when nothing is returned. So much code IS based on doing one thing if there is a value and another when there is not, so if that is the problem people are claiming needs fixing perhaps that is what needs addressing? string|false is a core element of most of PHP? -- 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] Re: Zend JIT Open Sourced
-Original Message- From: Dmitry Stogov [mailto:dmi...@zend.com] Sent: Friday, February 27, 2015 7:31 PM To: Anthony Ferrara Cc: Jordi Boggiano; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, It's not a single request cycle. JIT integrated into opcache, it compiles php script(s) of first access and stores code in shared memory. On following requests precompiled code is executed directly from shared memory. - The first request may be extremely slow (few minutes) That sounds more along the lines of AOT like I did with Recki rather than a true JIT (which compiles when a function is called). Judging from the jit_init() function, it appears like you're compiling the entire codebase ahead of time. Is that correct? Right now it compiles script (php file) at once. So yes, our JIT uses some kind of AOT approach, but completely transparently for the rest of PHP. Just to slightly further clarify - we don't compile the whole codebase at once, but we keep the existing semantics that every file is independent, may change independently of other files, and include() may end up load one file in one flow and another one in another flow. There's isn't any cross-file optimization. We also tried few different approaches to collect formation about hot functions and generate code only for them. Unfortunately, this didn't change the picture. (again, the picture being no performance gains in common Web apps). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 27/02/15 16:46, Damien Tournoud wrote: You probably haven't read the examples that I pasted. If you think that it makes sense to return an error code if the function is called with invalid arguments, it should be done consistently. The current behavior is just an absurdly inconsistent, it is really hard to find an argument in favor of it, other than the argument in favor of backward compatibility. That some changes to the logic of substr have been made is a fact. Negative values were added to read back from the end of the string a function that has been played with over time, # It is NOT OK to start reading past the end of the string, no, no. Bad programmer. If there are no characters left ... the string is empty. # But it is OK to ask for a bigger slice than the length of the string. Yes ... length is the MOST it will return, if less are available then that is all you can get. # It is also OK to read past the begining of the string, why not. If the reading point does not cut characters then yes this is consistent. If the length requested was '2', then I would expect 'a' and false which I think was what the 'bug fix' for PHP5.2.2 was supposed to do, but it was reverted later in 5.2.7 # On the other hand, it is NOT OK to stop reading before the end of the string. Bad programmer. Take 2 characters off the string ... empty string. This may not be what YOU want substr to do and it would perhaps be useful to ADD additional checks so that 'false' is returned when it can't created a string because of the 'invalid arguments', but type hints makes no difference to part of the jigsaw. What happens is exactly what one would expect ... nothing left in the string - an empty string. Having then to check every time for a '0' string length got shortened to simply being able to check 'is there a string' yes/no, and if no you can do something else. There is nothing inconsistent ... -- 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][RFC][VOTE] Enable error_handler callback parameters to be passed by reference
Le 13/02/2015 21:51, Thomas Bley a écrit : we'd like to initiate a vote on Allow error_handler callback parameters to be passed by reference: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference Hi, We've discussed this RFC with a few other people at AFUP, and we would be -1. Our reasons are probably the same as expressed here by others: updating the (more or less internal) error-messages doesn't feel right. And one can already use his own error handler to log what pieces of data are needed. Still, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Dmitry, It's not a single request cycle. JIT integrated into opcache, it compiles php script(s) of first access and stores code in shared memory. On following requests precompiled code is executed directly from shared memory. - The first request may be extremely slow (few minutes) That sounds more along the lines of AOT like I did with Recki rather than a true JIT (which compiles when a function is called). Judging from the jit_init() function, it appears like you're compiling the entire codebase ahead of time. Is that correct? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http
Le 26/02/2015 12:28, Michael Wallner a écrit : I forgot to formally declare a voting period, so I’ll do so now. Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do so until then. https://wiki.php.net/rfc/pecl_http#vote Hi, Not many of us at AFUP participated in our discussion about this proposal, but it seems we would be on the -1 side. Basically, even if a good HTTP layer is a good thing, we feel it kind of has its place more in user-land than in PHP itself. Adding this to PHP would mean more maintenance work on PHP itself, but also releases synced with releases of PHP -- which, in the end, is not that interesting for end-users, we think. In any case, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 27/02/15 13:45, Benjamin Eberlei wrote: Drupal admin interface (across the all pages): One new E_DEPRECATED warning, which again seems to catch a real bug - stripslsahes() operating on a boolean. All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Yes, weird behavior that substr(, 2, 2); for example returns false. But changing thatis just another evil BC break. Now I don' think that 'weird' ... Although the correct return should perhaps be 'null', but it's long been practice that s there is no result we get 'false' so how any places will have a sanity check based on the 'false' return? -- 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] Coercive STH - some real world tests and updated RFC
On Fri, Feb 27, 2015 at 2:57 PM, Lester Caine les...@lsces.co.uk wrote: On 27/02/15 13:45, Benjamin Eberlei wrote: Drupal admin interface (across the all pages): One new E_DEPRECATED warning, which again seems to catch a real bug - stripslsahes() operating on a boolean. All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Yes, weird behavior that substr(, 2, 2); for example returns false. But changing thatis just another evil BC break. Now I don' think that 'weird' ... Although the correct return should perhaps be 'null', but it's long been practice that s there is no result we get 'false' so how any places will have a sanity check based on the 'false' return? As an example i ported PDepend to work with coercive typehints, this is the quick and dirty patch: https://gist.github.com/beberlei/6a5a6b65839d35bb27f0 In longer chains of string handling, i just cast everything to (string) that could potentially return false here. Interestingly functions like is_infinite(), is_dir(), is_file() all expect correct types like float or string here although from the naming convention is_something i would expect it says just false on *anything* else (which it almost does right now). The patch also shows that this will lead to weird behavior when the PHP API is actually wrong like DOMNode::cloneNode() expecting an integer and not a boolean as argument, even though the PHP Documentation says it should be a boolean. I can literally forsee this is the way this kind of code will be fixed. Imho the problem is that the return values of php internal functions being string|false will lead to massive consecutive errors when passing this on to other internal unctions. -- 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] Coercive STH - some real world tests and updated RFC
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 2:38 PM Hi Zeev, On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote: Drupal homepage: One new E_DEPRECATED warning, which seems to catch a real bug, or at least faulty looking code: $path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean false. return $path; Drupal admin interface (across the all pages): One new E_DEPRECATED warning, which again seems to catch a real bug - stripslsahes() operating on a boolean. All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Damien It is not a bug. FALSE as a return value of substr() is the identificator for an error (e.g. invalid arguments), as it is stated in the documentation: Returns the extracted part of string; or FALSE on failure, or an empty string. [1] This is an example which shows, that Zeevs RFC helps to find bugs in applications. Because here are given invalid arguments to the method. In other languages for example Java, you'll get an IndexOutOfBoundsException [2] if you are trying the same ;-) 1: http://php.net/manual/en/function.substr.php 2: http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#substring%28int,%20int%29
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On Fri, Feb 27, 2015 at 2:37 PM, Damien Tournoud d...@damz.org wrote: Hi Zeev, On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote: Drupal homepage: One new E_DEPRECATED warning, which seems to catch a real bug, or at least faulty looking code: $path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean false. return $path; Drupal admin interface (across the all pages): One new E_DEPRECATED warning, which again seems to catch a real bug - stripslsahes() operating on a boolean. All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Yes, weird behavior that substr(, 2, 2); for example returns false. But changing that is just another evil BC break. Damien
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 23.02.2015 um 19:15 schrieb Nikita Popov: Voting on the engine exceptions RFC, which proposes to convert existing fatal and recoverable fatal errors into exceptions, has opened: https://wiki.php.net/rfc/engine_exceptions_for_php7#vote The primary vote requires a 2/3 majority, as this is a language change. A second vote will decide whether to use a BaseException based inheritance hierarchy. This vote uses a simple majority. I have voted yes on Allow exceptions in the engine and conversion of existing fatals? and no on Introduce and use BaseException? and would like to elaborate on the latter. I am sorry that I was unable to raise this concern earlier (did not really become aware of the RFC before it was put to the vote), but I would prefer the following: * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine This would be along the lines of what Java does. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 27/02/2015 14:31, Sebastian Bergmann wrote: Am 23.02.2015 um 19:15 schrieb Nikita Popov: Voting on the engine exceptions RFC, which proposes to convert existing fatal and recoverable fatal errors into exceptions, has opened: https://wiki.php.net/rfc/engine_exceptions_for_php7#vote The primary vote requires a 2/3 majority, as this is a language change. A second vote will decide whether to use a BaseException based inheritance hierarchy. This vote uses a simple majority. I have voted yes on Allow exceptions in the engine and conversion of existing fatals? and no on Introduce and use BaseException? and would like to elaborate on the latter. I am sorry that I was unable to raise this concern earlier (did not really become aware of the RFC before it was put to the vote), but I would prefer the following: * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine This would be along the lines of what Java does. +1 on that, and as it seems the BaseException is going to pass, it might be good to quickly draft another RFC to amend that part. It seems people in general favor the fact that catch(Exception $e) does not catch those new engine exceptions, but there hopefully would not be much resistance against a cleaner scheme than a BaseException class. Also the Error (and possibly Throwable) class/interface might be put in a PHP namespace and then we avoid any potential BC issues, but that's perhaps another voting point :) Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
-Original Message- From: Benjamin Eberlei [mailto:kont...@beberlei.de] Sent: Friday, February 27, 2015 1:19 PM To: Dmitry Stogov Cc: Zeev Suraski; PHP internals Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov dmi...@zend.com wrote: I've added the link to the patch https://github.com/php/php-src/pull/1125/files Thanks! First, the necessary PHPUnit changes (dev-master) to avoid errors: https://gist.github.com/beberlei/8a33ae940829f1186da2 - Doctrine DBAL testsuite: 8 failures - Doctrine ORM: Crashes unrelated after half the tests, but has about 30-50% failures like Symfony2 - Symfony2 Testsuite: 6215 failures - Twig: Tests: 1108, Assertions: 1616, Errors: 125. Thanks for the tests! We'll look into those. Now probably many of the failures are related to few code paths that need fixing, however I have to find out that and will be a lot of work. But this is the good PHP code! Judging by the fact WordPress, Magento and Drupal appear a lot cleaner - you have to wonder..? :) But on a more serious note, I don't think we should assume just about anything from the test suite as reflecting on real world app behavior. I'm not familiar with the Symfony test suite (yet), but I do know that the Symfony skeleton app ran cleanly without a single warning. Is it possible it's testing a lot of things with garbage input, as you would in unit tests, as the our own PHP test suite does? Those account for most of the failures. Also take into account that a project with that many tests (and specifically, failures) is probably not going to have just one or two people responsible for it, but more. It's not that you personally would have to fix Symfony, there are at least a dozen if not dozen people that would help out. For untested or older PHP code (and yes there is alot out there) i now have to collect the errors in production to find all the occurances. This is nothing i can just do whenever I want, I need a process to collect and fix this over time. Now every company needs this process for every project they have out there. I wish that were true, but in reality, migration is painfully slow and judging by the numbers, doesn't happen - more often than happening. The 'good' companies have ~5yrs after PHP 7 comes out and before PHP 7.x will no longer be supported (and that's according to my hope for a fast PHP 8 timeline; it may be longer as you suggested). Would all projects migrate by that timeline? Let's make a simpler question - would all projects migrate to PHP 7 by 2017, the year 5.6 theoretically stops being supported? We all know the answer to that. The good companies, the security conscious ones that do keep up with new versions, will likely be willing to invest the effort of fixing the code (or hiring someone to do it for them), especially as it'll help them make their apps more robust/secure. And especially as - at least so far - it seems that real world apps have not even a handful of issues per page. All that said, I think we must understand the huge gap between the very high degree of test failures you're seeing in test suites, and the almost none we're seeing in real world apps. If it's similar to the PHP test suite, it's a non-issue, and even if it would take some work to fix the unit tests, it's well worth it. If it's legit, but as you're guessing, may just be several common paths of code that will do away with most of the failures - it's still worth it. Investing several days over the course of several years is great ROI for the value it brings. If, however, the test suite does find a multitude of many different issues - it may bring me to reconsider the RFC, as I told Anthony a few days ago - especially if the signal to noise ratio would be bad. After the results we've seen with real world apps I find it hard to believe, but it's certainly a possible scenario. At the end of the day, it boils down to how much real work do we think will be required to update real world apps out there. Let's also not set unreasonable bars for this change compared to other compatibility breakages we've done (and are stil doing) over the years - again, most of which didn't bring any tangible value to developers (which this change does, a lot). And the typical agency has hundrets/thousands of drupal, typo3, wordpress installations out there Correct, but would you have to patch each one separately? You'd have to install updated core for Drupal, Typo3, WP - which you commonly have to do anyway if you care about security. Then there'd be some work to get your common custom modules that you developed update - between the two of those, that should account for most of the code. It's not as if you're going to start with each deployment from scratch, is it? Anyway, thanks again for running the tests - we'll definitely need to understand that better. Thanks, Zeev -- PHP
[PHP-DEV] Re: Zend JIT Open Sourced
Dmitry, Thanks for the opportunity to read, that's cool ;) Cheers Joe On Fri, Feb 27, 2015 at 12:10 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instruction. Don't merge it with master. It may work today but will stop working tomrrow. Disclaimers: - It's an experiment, and is not in any way ready for anything. In the future we may try to implement JIT quite different from this PoC. - I'm not planning to invest into it in the near future. (PHP-7 takes all my time) Consider it available for academic purposes only at this point. Enjoy! Thanks. Dmitry.
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
Hi Zeev, On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote: Drupal homepage: One new E_DEPRECATED warning, which seems to catch a real bug, or at least faulty looking code: $path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean false. return $path; Drupal admin interface (across the all pages): One new E_DEPRECATED warning, which again seems to catch a real bug - stripslsahes() operating on a boolean. All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Damien
Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
Matthew, Thanks a bunch for going through this and writing such a detailed report. On 27/02/2015 00:29, Matthew Weier O'Phinney wrote: ### STHv5 [snip] Analysis I did not expect the float value to be coerced, particularly as it had a fractional part. Yes, I understand that this is how casting _currently_ works in PHP, and that the patch uses the current casting rules. However, I'd expect that any float with a fractional value would not be cast to an integer; doing so is lossy, and can lead to unexpected results. The strict_types mode operated how I would expect it, but meant I was forced to add the declaration to the top of the file. Which leads to this: My tests operated differently in strict vs normal mode. That means my code does, too. Testing both modes would be difficult to do in an automated fashion; essentially, you're left needing to choose to support one mode or the other. This goes back to the point I was making earlier this week: I worry that having two modes will lead to a schism in userland libraries: those that support strict, and those that do not; there will be little possibility of testing both. I think this last bit is misguided. Your *tests* are running differently depending if they are in strict and weak mode, that is correct, but the code's behavior itself is not changing based on the test suite's strictness. That does not mean your library is tested to run in mode X or Y, it just means your test suite's correctness relies on testing the PHP type hints in this case, and it breaks when you change the way the hints behave. For users the code will work the same no matter if they are in strict or weak mode, but if they are in weak mode they should indeed watch out if they send floats they will be silently truncated as those are the rules of weak mode. In the end: kudos to everyone who is working on these patches and RFCs. I'm excited about scalar type hints in PHP 7! I agree with Benjamin's conclusion that having both RFCs combined might be for the best. At the very least lossy float-int should be disabled in the STHv5's weak mode because that's dangerous and unlikely to occur IMO. The other casting changes from STHcoerce I am not sure if they're for the best or not. I am a bit worried we change things arbitrarily based on who has a good argument not to change them, and we might end up with a completely inconsistent set of casting rules. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On Fri, Feb 27, 2015 at 2:37 PM, Damien Tournoud d...@damz.org wrote: Hi Zeev, On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote: Drupal homepage: One new E_DEPRECATED warning, which seems to catch a real bug, or at least faulty looking code: $path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean false. return $path; Drupal admin interface (across the all pages): One new E_DEPRECATED warning, which again seems to catch a real bug - stripslsahes() operating on a boolean. All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Damien This kind of code here exhibits the failure: https://github.com/pdepend/pdepend/blob/master/src/main/php/PDepend/Source/Language/PHP/PHPTokenizerInternal.php#L584 This is classic PHP style code where you rely on the implicit casting to make the algorithm work for you. if substr() here returns false, then the error is: 1767) PDepend\Source\Parser\UnstructuredCodeTest::testParserHandlesNonPhpCodeInFileProlog strlen() expects parameter 1 to be string, boolean given /home/benny/code/php/workspace/pdepend/src/main/php/PDepend/Source/Language/PHP/PHPTokenizerInternal.php:586 The funny thing is that the fix for this is: - substr($image, strrpos($image, \n) + 1) + (string)substr($image, strrpos($image, \n) + 1) Which is that sort of casting that is put forward as argument against the dual/strict mode.
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Zeev, Right now it compiles script (php file) at once. So yes, our JIT uses some kind of AOT approach, but completely transparently for the rest of PHP. Just to slightly further clarify - we don't compile the whole codebase at once, but we keep the existing semantics that every file is independent, may change independently of other files, and include() may end up load one file in one flow and another one in another flow. There's isn't any cross-file optimization. We also tried few different approaches to collect formation about hot functions and generate code only for them. Unfortunately, this didn't change the picture. (again, the picture being no performance gains in common Web apps). Well, I just want to make one clarification here to your point: there's no performance gains to this AOT approach for common web apps. It's not really fair to judge a true JIT implementation based on this because it lacks crucial runtime information that a real JIT compiler would have (such as input types, values, etc). So it would be left generating generic native code instead of specific code. I just want to point out that the results here aren't really applicable to a JIT approach. And that should be made clear when discussing it. That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend JIT Open Sourced
hi, On Fri, Feb 27, 2015 at 4:10 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instruction. Don't merge it with master. It may work today but will stop working tomrrow. Disclaimers: - It's an experiment, and is not in any way ready for anything. In the future we may try to implement JIT quite different from this PoC. - I'm not planning to invest into it in the near future. (PHP-7 takes all my time) Consider it available for academic purposes only at this point. Fantastic move! The way to do it! Thanks a lot!. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Feb 27, 2015, at 7:12 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Yes I think we can definitely do that. It is an interesting experiment and clarified also that JIT was less interesting in the short term as we can all observe by the fabulous results of the current PHP 7 runtime. But absolutely worth discussing post 7 as there surely are interesting opportunities. Andi Thanks again Anthony On Fri, Feb 27, 2015 at 7:10 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instruction. Don't merge it with master. It may work today but will stop working tomrrow. Disclaimers: - It's an experiment, and is not in any way ready for anything. In the future we may try to implement JIT quite different from this PoC. - I'm not planning to invest into it in the near future. (PHP-7 takes all my time) Consider it available for academic purposes only at this point. Enjoy! Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About optimization for compiler
Am 27.02.2015 um 16:12 schrieb Xinchen Hui larue...@gmail.com: On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and not two. caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. Doing it in opcache would currently need to play with extension-defined opcodes etc. I'd rather not be so invasive in opcache that after the optimizations it cannot run in a normal Zend VM anymore. (also a reason why integrating into Zend would be a good idea) or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major ABI/API breaks. The compiler step is usually also rather left untouched by most extensions. If we want to do this, we could target 7.1 without major issues. thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
+1 on Sebastian's suggestion. =) I volunteer to either update the RFC or create a new one to resolve this once Exceptions in the engine passes (which looks like a reality already to me). Just tell me which approach I should take and I'll happily write the RFC. []s, On Fri, Feb 27, 2015 at 9:47 AM, Jordi Boggiano j.boggi...@seld.be wrote: On 27/02/2015 14:31, Sebastian Bergmann wrote: Am 23.02.2015 um 19:15 schrieb Nikita Popov: Voting on the engine exceptions RFC, which proposes to convert existing fatal and recoverable fatal errors into exceptions, has opened: https://wiki.php.net/rfc/engine_exceptions_for_php7#vote The primary vote requires a 2/3 majority, as this is a language change. A second vote will decide whether to use a BaseException based inheritance hierarchy. This vote uses a simple majority. I have voted yes on Allow exceptions in the engine and conversion of existing fatals? and no on Introduce and use BaseException? and would like to elaborate on the latter. I am sorry that I was unable to raise this concern earlier (did not really become aware of the RFC before it was put to the vote), but I would prefer the following: * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine This would be along the lines of what Java does. +1 on that, and as it seems the BaseException is going to pass, it might be good to quickly draft another RFC to amend that part. It seems people in general favor the fact that catch(Exception $e) does not catch those new engine exceptions, but there hopefully would not be much resistance against a cleaner scheme than a BaseException class. Also the Error (and possibly Throwable) class/interface might be put in a PHP namespace and then we avoid any potential BC issues, but that's perhaps another voting point :) Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 6:40 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 27/02/2015 15:19, Andi Gutmans wrote: On Feb 27, 2015, at 7:12 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Yes I think we can definitely do that. It is an interesting experiment and clarified also that JIT was less interesting in the short term as we can all observe by the fabulous results of the current PHP 7 runtime. But absolutely worth discussing post 7 as there surely are interesting opportunities. Do you have a one line summary of why it's useless for real world applications? Is it just because they don't do enough number crunching compared to I/O or is it a matter of the JIT not kicking in fast enough to improve things in a single request cycle? It's not a single request cycle. JIT integrated into opcache, it compiles php script(s) of first access and stores code in shared memory. On following requests precompiled code is executed directly from shared memory. - The first request may be extremely slow (few minutes) - The speed improvement on the following request may be insignificant or even negative. It very depends on application, but from my experience only small apps got significant improvements. This may be explained by huge increase in ICACHE and ITLB misses, but I'm not 100% sure. I am biased but if it improves the bench code so much it still sounds like a potentially good things for specific code like the composer dependency solver :) Yeah. Probably, if we position this work as a JIT for hotspots only, or even enable it for some functions manually we may get better results. Thanks. Dmitry, Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 4:54 PM Hi Christian, On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de wrote: It is not a bug. FALSE as a return value of substr() is the identificator for an error (e.g. invalid arguments), as it is stated in the documentation: [...] It is documented that way and it is not a bug are two very different things. That’s not true. Quoting Wikipedia A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. [1] In this case FALSE is an expected result and it is intended. And as I said other languages are going the same way. In that case, the semantics of `substr()` are just wrong. It makes a lot more sense for a sub-string function to silently allow reading before the beginning and past the end of a string. Just because it makes more sense for you, it does not imply that it makes more sense for everybody. In my opinion it makes sense to return an error code if a function is called with invalid arguments. This behavior is unpredictable, and as a consequence using `substr()` properly would require a lot of painful and unnecessary up-front checks. I agree with you, here. With the coercive patch this will lead to More checks. But that's different from it is a bug ;-) 1: http://en.wikipedia.org/wiki/Software_bug
[PHP-DEV] Re: About optimization for compiler
Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com mailto:larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) Bob
Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
Am 27.02.2015 um 01:29 schrieb Matthew Weier O'Phinney: - PHPUnit passes a boolean false to `debug_backtrace()`... which is documented as expecting an integer! (There are actually several constant values it accepts, all of which are integer values.) In this case, PHPUnit is relying on the fact that the engine casts booleans to the integers 0 and 1. (Zeev has written to the list already indicating that this coercion path will be supported in the patch.) - PHPUnit is passing the results of $reflector-getDocComment() blindly to substr() and preg_match*(). getDocComment() is documented as returning EITHER a string OR boolean false. Again, PHPUnit is relying on PHP to cast boolean false to an empty string. (Zeev has also indicated this coercion path may be re-introduced.) Pull requests for PHPUnit would be appreciated ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Dmitry Stogov wrote on 27/02/2015 15:56: On Fri, Feb 27, 2015 at 6:40 PM, Jordi Boggianoj.boggi...@seld.be wrote: On 27/02/2015 15:19, Andi Gutmans wrote: On Feb 27, 2015, at 7:12 AM, Anthony Ferraraircmax...@gmail.com wrote: Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Yes I think we can definitely do that. It is an interesting experiment and clarified also that JIT was less interesting in the short term as we can all observe by the fabulous results of the current PHP 7 runtime. But absolutely worth discussing post 7 as there surely are interesting opportunities. Do you have a one line summary of why it's useless for real world applications? Is it just because they don't do enough number crunching compared to I/O or is it a matter of the JIT not kicking in fast enough to improve things in a single request cycle? It's not a single request cycle. JIT integrated into opcache, it compiles php script(s) of first access and stores code in shared memory. On following requests precompiled code is executed directly from shared memory. This reminds me of an idea I had a while ago - with OpCache, and potentially JIT, relying on shared memory for optimisations, command-line scripts (e.g. background processing via cron or supervisord) are getting left behind in terms of performance. So I wonder if it would be possible to implement a FastCLI application server similar to FastCGI, which could be sent multiple requests representing POSIX command invocations, and serve them from a threaded environment. So instead of php composer.phar install, you'd run php-fastcli --port 5 composer.phar install, which would attach to a running FastCLI server. Has anyone ever looked at such a thing? It seems like it would be useful for other languages as well, in exactly the way FastCGI is. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Am 27.02.2015 um 16:12 schrieb Anthony Ferrara: Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? What Joe and Anthony said :-) Thanks for sharing this with the community and I'll be looking forward to the promised documentation of decisions etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 16:12 schrieb Xinchen Hui larue...@gmail.com: On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and not two. caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. Doing it in opcache would currently need to play with extension-defined opcodes etc. I'd rather not be so invasive in opcache that after the optimizations it cannot run in a normal Zend VM anymore. (also a reason why integrating into Zend would be a good idea) or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major ABI/API breaks. The compiler step is usually also rather left untouched by most extensions. If we want to do this, we could target 7.1 without major issues. I think so. This may affect some binary interface but should be completely transparent for users. Thanks. Dmitry. thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ Bob
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
Cristian, All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Damien It is not a bug. FALSE as a return value of substr() is the identificator for an error (e.g. invalid arguments), as it is stated in the documentation: Returns the extracted part of string; or FALSE on failure, or an empty string. [1] This is an example which shows, that Zeevs RFC helps to find bugs in applications. Because here are given invalid arguments to the method. In other languages for example Java, you'll get an IndexOutOfBoundsException [2] if you are trying the same ;-) Well, it depends on your definition of bug. If you look at PHPUnit's TestSuite::isTestMethod method, you'll see this: $doc_comment = $method-getDocComment(); return strpos($doc_comment, '@test') !== false || strpos($doc_comment, '@scenario') !== false; Now, with the coercive mode (and my strict mode), that will error if the method does not have a docblock. The reason is that `$method-getDocComment()` returns false if one does not exist. Is that a bug? Well, semantically, maybe. But from the application level, no. Passing the boolean result to `strpos` directly ensures that the result will be `bool(false)`. So the overall method behaves as expected returning true in the correct context (it's a test method) and false in incorrect contexts (it's not). So did the coercive mode find a bug? Not really. It found something that may have worked in a way you didn't expect it to, but it wasn't a bug (at least to the application). Now, if you care about types and type changes, then yes, that is a bug. And that's why the dual-mode RFC gives you the choice. You can choose to care about types or not. Not some weird hybrid where you have to care even if the code is practically correct... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
On Fri, Feb 27, 2015 at 4:25 PM, Sebastian Bergmann sebast...@php.net wrote: Am 27.02.2015 um 01:29 schrieb Matthew Weier O'Phinney: - PHPUnit passes a boolean false to `debug_backtrace()`... which is documented as expecting an integer! (There are actually several constant values it accepts, all of which are integer values.) In this case, PHPUnit is relying on the fact that the engine casts booleans to the integers 0 and 1. (Zeev has written to the list already indicating that this coercion path will be supported in the patch.) - PHPUnit is passing the results of $reflector-getDocComment() blindly to substr() and preg_match*(). getDocComment() is documented as returning EITHER a string OR boolean false. Again, PHPUnit is relying on PHP to cast boolean false to an empty string. (Zeev has also indicated this coercion path may be re-introduced.) Pull requests for PHPUnit would be appreciated ;-) https://gist.github.com/beberlei/8a33ae940829f1186da2 - these are the necessary changes for dev-msater to run on php7+coercive patch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On 27/02/2015 15:19, Andi Gutmans wrote: On Feb 27, 2015, at 7:12 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Yes I think we can definitely do that. It is an interesting experiment and clarified also that JIT was less interesting in the short term as we can all observe by the fabulous results of the current PHP 7 runtime. But absolutely worth discussing post 7 as there surely are interesting opportunities. Do you have a one line summary of why it's useless for real world applications? Is it just because they don't do enough number crunching compared to I/O or is it a matter of the JIT not kicking in fast enough to improve things in a single request cycle? I am biased but if it improves the bench code so much it still sounds like a potentially good things for specific code like the composer dependency solver :) Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
Hi Christian, On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de wrote: It is not a bug. FALSE as a return value of substr() is the identificator for an error (e.g. invalid arguments), as it is stated in the documentation: [...] It is documented that way and it is not a bug are two very different things. In that case, the semantics of `substr()` are just wrong. It makes a lot more sense for a sub-string function to silently allow reading before the beginning and past the end of a string. Moreover, the *conditions* under which `substr()` returns FALSE looks completely arbitrary, see http://3v4l.org/gtFjk -- in a nutshell: so it is OK to read past the beginning, it is OK to try to get more characters than the string has, but it is NOT OK to try to start reading past the end? This behavior is unpredictable, and as a consequence using `substr()` properly would require a lot of painful and unnecessary up-front checks. It traditionally did not matter, because of the fluid scalar casts. But if we want now to introduce stricter casts, we are going to have to tackle this problem, we cannot just dismiss it as a programming error. Damien
[PHP-DEV] Re: Zend JIT Open Sourced
Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Thanks again Anthony On Fri, Feb 27, 2015 at 7:10 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instruction. Don't merge it with master. It may work today but will stop working tomrrow. Disclaimers: - It's an experiment, and is not in any way ready for anything. In the future we may try to implement JIT quite different from this PoC. - I'm not planning to invest into it in the near future. (PHP-7 takes all my time) Consider it available for academic purposes only at this point. Enjoy! Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 6:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? The big practical problem. That without opcache optimizations are executed on each request. This means that they may require more time to work, than the gain from bytecode improvement. I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. Yes. Opcache is extremely depends on engine. Moving optimizer from opcache to ZE may be a good idea. Technically it's possible, but I'm not sure when and how it should be done. I think optimizer need to be refactored as well, but this is only for 7.1 probably. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) Your ZEND_SWITCH optimization makes sense. Unfortunately, implementation is a bit messy (not intuitive). The biggest problem that it doesn't fit with existing Optimizer. For now I don't know how to change Control Flow Graph representation and corresponding pass to support ZEND_SWITCH. Thanks. Dmitry. Bob
RE: [PHP-DEV] Re: Zend JIT Open Sourced
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, February 27, 2015 9:36 PM To: Dmitry Stogov Cc: Zeev Suraski; Jordi Boggiano; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to STDOUT on every single iteration. Except stdout is buffered too (www.turnkeylinux.org/blog/unix-buffering). Perhaps there's some difference there, but it's not nearly as obvious as you claim (let alone the other stuff in the other email, but let's leave that aside). Personally, my money would be on glibc stdout's buffering being more efficient than our output buffering layer. But you're welcome to test. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, it's possible. But I don't think it's likely. It really smells to me like bias in the testing methodology. (and the lack of an -O3 result is suspicious as well). No. it true, but of course it's not 100% fair. gcc compiles files for x86 or x86_64 platform in general. When we compile in run-time we may relay on knowledge of our CPU. In this case LLVM generates AVX instructions, while gcc SSE2. Looking into assembler code, you may see that PHP even not inferred type of all variables and makes few unnecessary check in the loop, but modern CPU are so smart that the code looking mach worse work with the same speed as (gcc -O2). Unfortunately it works in the other direction as well. gcc -O2 -mavx will outperform us :) And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to STDOUT on every single iteration. So you are intentionally not benchmarking the output in the PHP version (you even explicitly call ob_start()) but are benchmarking it in every other version. So in fact, the PHP code does something different than the rest of the code. Sneaky sneaky. Also completely fake. A proper methodology would have explicitly disabled any buffer so that the tests all tested the same thing. Or even better, build up an internal buffer in all of the implementations. That way you can compare the computation and not rely on STDOUT (terminal) response. this also may make some difference, but I think PHP stream layer is not as good as C. just profile it with Linux perf, oprofile, callgrind, ... perf record command perf report -n Thanks. Dmitry Anthony
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Dmitry, Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. I assure you that was not the intent (I called the benchmark sneaky and fake, which it is). So if you interpreted it as an insult, I apologize sincerely. I did not intend to insult you personally at all with that remark. It was only meant as a comment about the code that was posted. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
Hi Lester, On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine les...@lsces.co.uk wrote: This may not be what YOU want substr to do and it would perhaps be useful to ADD additional checks so that 'false' is returned when it can't created a string because of the 'invalid arguments', but type hints makes no difference to part of the jigsaw. What happens is exactly what one would expect ... nothing left in the string - an empty string. Having then to check every time for a '0' string length got shortened to simply being able to check 'is there a string' yes/no, and if no you can do something else. There is nothing inconsistent ... Please, read the examples again, the current behavior is nothing but inconsistent: substr(a, 1) = FALSE substr(a, -300) = But anyway, that's not even the point. The point is that return values that worked in a world of transparent type-jungling will not work in a world of stricter typing checks. Which means that we need: (1) To accept that for now casting FALSE to the empty string is the right thing to do; until / unless: (2) We fixed all the common functions in the standard library so that they stop returning inconsistent types, in particular in the cases where it should not even be a debate what is the right thing to do (for substr, if the arguments point to an empty slice, return the empty string). Damien
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Dmitry, That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, it's possible. But I don't think it's likely. It really smells to me like bias in the testing methodology. (and the lack of an -O3 result is suspicious as well). And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to STDOUT on every single iteration. So you are intentionally not benchmarking the output in the PHP version (you even explicitly call ob_start()) but are benchmarking it in every other version. So in fact, the PHP code does something different than the rest of the code. Sneaky sneaky. Also completely fake. A proper methodology would have explicitly disabled any buffer so that the tests all tested the same thing. Or even better, build up an internal buffer in all of the implementations. That way you can compare the computation and not rely on STDOUT (terminal) response. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
Zeev, On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, February 27, 2015 10:21 PM To: Dmitry Stogov Cc: Zeev Suraski; Jordi Boggiano; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced Dmitry, Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. Anthony, I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. You could have picked wrong, problematic, inadequate, poor - or a dozen other adjectives that don't literally claim that Dmitry did it intentionally to give an unfair advantage to the PHP implementation (which, just in case anybody's wondering, you also wrote literally, using the word 'intentionally' in the previous sentence. You're not clairvoyant and you have no idea whether Dmitry did it intentionally or not, and the adjectives you used mean negative intent. If you apologize, apologize for real and not with disclaimers that it was taken out of context. It wasn't. And I have no idea why I had to bring it to your attention. If somehow you slipped, you should have fixed it yourself immediately. I had intended it as a remark about the code. Not about him personally, not about you, not about Zend. The presence of the explicit buffering code indicates that it wasn't an accident. Whether it was intentional for extra speed or not, it's still an intentionally different codepath between the rest of the implementations. One that in practice can have non-trivial differences over outputting directly. If you took that as an insult against him, you or Zend, then I'm sorry. I still believe the benchmark is very subtly broken, and hence the results are invalid. I apologized to any insult that may have been misdirected at the person. Please, can we talk about code separately from the person? A good person can produce bad code. That happens. I know, I produce a lot of it. I don't take insult when people call my code bad. And I hope we can call code bad. Because if we can't, we can never grow or move on as people or as a project. So I do apologize to the person. I don't to the code. Anthony PS: Dmitry accepted my apology. Can you please? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, it's possible. But I don't think it's likely. It really smells to me like bias in the testing methodology. (and the lack of an -O3 result is suspicious as well). And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to STDOUT on every single iteration. So you are intentionally not benchmarking the output in the PHP version (you even explicitly call ob_start()) but are benchmarking it in every other version. So in fact, the PHP code does something different than the rest of the code. Sneaky sneaky. Also completely fake. Please, be polite. We opened sources, and the sources of benchmarks. Anyone can repeat this. Smart people may analyze results themselves before claiming others. I think you are smart person, and I respect the things you are doing. Thanks. Dmitry. A proper methodology would have explicitly disabled any buffer so that the tests all tested the same thing. Or even better, build up an internal buffer in all of the implementations. That way you can compare the computation and not rely on STDOUT (terminal) response. Anthony
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 11:21 PM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. I assure you that was not the intent (I called the benchmark sneaky and fake, which it is). So if you interpreted it as an insult, I apologize sincerely. I did not intend to insult you personally at all with that remark. It was only meant as a comment about the code that was posted. Not a problem. I wouldn't even notice this because my bad English knowledge allows me to filter this :) Dmitry. Anthony
RE: [PHP-DEV] Re: Zend JIT Open Sourced
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, February 27, 2015 10:21 PM To: Dmitry Stogov Cc: Zeev Suraski; Jordi Boggiano; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced Dmitry, Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. Anthony, I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. You could have picked wrong, problematic, inadequate, poor - or a dozen other adjectives that don't literally claim that Dmitry did it intentionally to give an unfair advantage to the PHP implementation (which, just in case anybody's wondering, you also wrote literally, using the word 'intentionally' in the previous sentence. You're not clairvoyant and you have no idea whether Dmitry did it intentionally or not, and the adjectives you used mean negative intent. If you apologize, apologize for real and not with disclaimers that it was taken out of context. It wasn't. And I have no idea why I had to bring it to your attention. If somehow you slipped, you should have fixed it yourself immediately. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 9:55 PM, Anthony Ferrara ircmax...@gmail.com wrote: Zeev, Right now it compiles script (php file) at once. So yes, our JIT uses some kind of AOT approach, but completely transparently for the rest of PHP. Just to slightly further clarify - we don't compile the whole codebase at once, but we keep the existing semantics that every file is independent, may change independently of other files, and include() may end up load one file in one flow and another one in another flow. There's isn't any cross-file optimization. We also tried few different approaches to collect formation about hot functions and generate code only for them. Unfortunately, this didn't change the picture. (again, the picture being no performance gains in common Web apps). Well, I just want to make one clarification here to your point: there's no performance gains to this AOT approach for common web apps. It's not really fair to judge a true JIT implementation based on this because it lacks crucial runtime information that a real JIT compiler would have (such as input types, values, etc). So it would be left generating generic native code instead of specific code. I just want to point out that the results here aren't really applicable to a JIT approach. And that should be made clear when discussing it. Nobody talk about JIT in general, only about this PoC. And yes, some other approaches may provide better gain. At least I think so. However, we may just guess, until implement them. That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) Thanks. Dmitry. Anthony
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 27/02/15 20:28, Damien Tournoud wrote: Hi Lester, On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk wrote: This may not be what YOU want substr to do and it would perhaps be useful to ADD additional checks so that 'false' is returned when it can't created a string because of the 'invalid arguments', but type hints makes no difference to part of the jigsaw. What happens is exactly what one would expect ... nothing left in the string - an empty string. Having then to check every time for a '0' string length got shortened to simply being able to check 'is there a string' yes/no, and if no you can do something else. There is nothing inconsistent ... Please, read the examples again, the current behavior is nothing but inconsistent: substr(a, 1) = FALSE substr(a, -300) = ? That was the case prior to PHP5.2.1 The fixes in 5.2.2 were not commonly accepted but give false for both, but 5.2.7 and later give false and a which is what was the preferred result at the time. Unless we are seeing something different, I'm only seeing a or false for a current output of all your examples. But anyway, that's not even the point. The point is that return values that worked in a world of transparent type-jungling will not work in a world of stricter typing checks. Which means that we need: (1) To accept that for now casting FALSE to the empty string is the right thing to do; until / unless: (2) We fixed all the common functions in the standard library so that they stop returning inconsistent types, in particular in the cases where it should not even be a debate what is the right thing to do (for substr, if the arguments point to an empty slice, return the empty string). That side I totally agree with. The 'fixes' posted so far such as adding (string) or replacing false by 0 should be enough to prevent adoption, and personally I find the strict option just as problematic. -- 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] Coercive STH - some real world tests and updated RFC
Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
All,
We've been working in the last few days to test and tune the Coercive STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Can we try the patch ourselves? I would love to run it against some
libraries as well.
Before diving into the results, we did update the RFC
(wiki.php.net/rfc/coercive_sth) - with the most notable difference being
allowing NULL-scalar conversions, for two reasons - it's not uncommon for
code to use 'null' as a way to denote an empty optional parameter to for
internal functions, and many internal functions seem to rely on that
behavior themselves. It should be possible to alter this behavior in the
future by changing the internal functions to explicitly handle NULL inputs
as 'please use the default value' - but it's outside the scope of the RFC.
This RFC trying to simpliy and cleanup the coercison rules, having two
different conversion rules for NULL-scalar
depending on userland or internal is counter-productive and bad. The
behavior you describe as null being
empty value is wide-spread in PHP userland code as well.
In addition, coercion from scalar to boolean is now limited only to
integer - which seems to be the most popular use case; Beforehand,
coercion was also allowed from float and string - but based on feedback
from Mike, we're reconsidering accepting strings again.
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
I agree with Pierre here, it would be super helpful if we had a log in the
RFC of the actual changes that will be happening.
As in Francois original patch this seems to be a game of having 20 changes
and then picking which ones to do and which not.
Now to the tests we ran. The goal was to see what kind of effect the
changes to the internal function APIs had on real world apps with large
codebase. The test methodology was done by placing a debugger breakpoint
on zend_error, to ensure no error gets lost in the ether of settings or
callbacks. Here are the results:
Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
real bug, or at least faulty looking code:
$path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean
false.
return $path;
Drupal admin interface (across the all pages): One new E_DEPRECATED
warning, which again seems to catch a real bug - stripslsahes() operating
on a boolean.
Magento homepage (w/ Magento's huge sample DB): One new E_DEPRECATED
warning, again, seems to be catching a real bug of 'false' being fed as
argument 1 of in json_decode() - which is expecting a string full of json
there.
WordPress homepage: One new E_DEPRECATED warning, again, seems to be
catching a real bug of 'false' being fed as argument 1 of substr().
Zend Framework 2 skeleton app: Zero new E_DEPRECATED warnings.
Symfony ACME app: Zero new E_DEPRECATED warnings (across the app).
I was expecting this, because the rule changes are mostly in regard to not
accepting
invalid input, so what you need to test is all the edge cases.
Say I rely on a validation in count() somewhere in the code to implicitly
validate its an array:
if (count($_GET['filters'])) {
echo Filtering my query;
}
This would work in the happy path case, because i have a filter set. But
maybe
there is some invalid state i can get into and only then the E_DEPRECATED
is produced.
The homepages of popular systems being the essential happy path for a
project, I wouldnt expect many errors to occur.
As I'm sure you know, the above tests invoke a huge number of lines of
code in total, handling filesystem ops, database ops and all sorts of
other things. This is much of the mini test suite that we use to test
PHP's performance and compatibility (e.g. phpng, now PHP 7). So while
this isn't proof that code in the wild isn't going to have more issues -
it's a pretty good initial indication regarding the level of 'breakage' we
can expect. I'm putting breakage in quotes, as people would have several
years to fix these few issues, before the E_DEPRECATED becomes an error
(or an exception, if the engine exceptions RFC passes).
In terms of the test suite (.phpts), the changes cause approximately 700
extra tests to fail out of 13,700, in comparison to w/o the patch.
However, even though I didn't have a chance to go over all of them, it
seems that the vast majority of the failed tests are tests that were
intentionally designed to cover the exact parameter passing behavior,
rather than real likely real world code pieces. A huge number of the
internal functions have this in their test suites:
$variation = array(
'float 10.5' = 10.5,
'float -10.5' = -10.5,
'float 12.3456789000e10' = 12.3456789000e10,
'float -12.3456789000e10' = -12.3456789000e10,
'float .5' = .5,
);
Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
Hey:
On Fri, Feb 27, 2015 at 3:59 PM, Xinchen Hui larue...@php.net wrote:
Hey:
On Fri, Feb 27, 2015 at 10:06 AM, François Laupretre franc...@php.net wrote:
De : Matthew Weier O'Phinney [mailto:matt...@zend.com]
- PHPUnit passes a boolean false to `debug_backtrace()`... which is
documented
as expecting an integer! (There are actually several constant values it
accepts, all of which are integer values.) In this case, PHPUnit is
relying
on the fact that the engine casts booleans to the integers 0 and 1. (Zeev
has
written to the list already indicating that this coercion path will be
supported in the patch.)
AFAIK, we won't support boolean to integer. IMO, considering Boolean as
integer is a bug and must not be supported.
in a internal developer's view:
bool false === 0, bool true == 1;
maybe this case should be supported?
considering such usage :
if (substr($str, strrpos($str, ':delimiter:')) {
}
this is not a really world usage, I just made it up, this codes is try
to find a last part of a string which is contacted with a dimileter
:delimiter:
sorry, the example is wrong, but I think you may get my idea.
a works example is:
find the first part:
substr($str, 0, strpos($str, :delimiter:))
which is common used,, right?
thanks
like a:delimiter:b, c:dilimiter:d
it works well before, because, if there is no match, it returns false
before.. (which we will think it's '0')
then the whole $str is returned..
but if we don't support bool false - 0?
thanks
- PHPUnit is passing the results of $reflector-getDocComment() blindly to
substr() and preg_match*(). getDocComment() is documented as returning
EITHER
a string OR boolean false. Again, PHPUnit is relying on PHP to cast
boolean
false to an empty string. (Zeev has also indicated this coercion path may
be
re-introduced.)
The same as above for bool - string.
I hope you're wrong because I wouldn't like supporting boolean to scalar
back again.
Your test demonstrates this because you found undetected bugs. I am more and
more sure that, what I first said as a joke, will prove true : during the
next years, STH will be used mostly as a debugging tool, proving opposite
arguments were FUD or, at least, phantasm.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
Matthew, On Fri, Feb 27, 2015 at 1:29 AM, Matthew Weier O'Phinney matt...@zend.com wrote: I've taken some time the last couple days to compile both the Scalare Type Hints v0.5 (heretofor STHv5) and Coercive Scalar Type Hints (heretofore STHcoerce) patches and test some code against them. In each case, I modified the `Phly\Http\Response` class from my phly/http package to add scalar type hints, remove previous argument validation, and then ran the unit tests. Here's my details of the experience, and analysis. ### STHv5 With STHv5, my tests failed out of the box. First, I needed to add an error handler that would convert the E_RECOVERABLE_ERROR to an InvalidArgumentException so that I would get useful error messages from PHPUnit. Next, once I had done that, I had tests that were throwing invalid input at methods, and validating that the invalid arguments were caught. This worked in all but one specific case: passing a float value to an argument expecting an integer. In this particular case, the value was coerced to an integer, albeit lossily, and no error was raised. When I changed my test case to operate under strict_types mode, the test executed as I had originally expected, and succeeded. Analysis I did not expect the float value to be coerced, particularly as it had a fractional part. Yes, I understand that this is how casting _currently_ works in PHP, and that the patch uses the current casting rules. However, I'd expect that any float with a fractional value would not be cast to an integer; doing so is lossy, and can lead to unexpected results. The strict_types mode operated how I would expect it, but meant I was forced to add the declaration to the top of the file. Which leads to this: My tests operated differently in strict vs normal mode. That means my code does, too. Testing both modes would be difficult to do in an automated fashion; essentially, you're left needing to choose to support one mode or the other. This goes back to the point I was making earlier this week: I worry that having two modes will lead to a schism in userland libraries: those that support strict, and those that do not; there will be little possibility of testing both. ### STHcoerce With STHcoerce, my tests also failed out of the box, but not for the same reason. Instead, I had a bunch of errors reported based on code that PHPUnit was executing! In this case, I discovered that: - PHPUnit passes a boolean false to `debug_backtrace()`... which is documented as expecting an integer! (There are actually several constant values it accepts, all of which are integer values.) In this case, PHPUnit is relying on the fact that the engine casts booleans to the integers 0 and 1. (Zeev has written to the list already indicating that this coercion path will be supported in the patch.) - PHPUnit is passing the results of $reflector-getDocComment() blindly to substr() and preg_match*(). getDocComment() is documented as returning EITHER a string OR boolean false. Again, PHPUnit is relying on PHP to cast boolean false to an empty string. (Zeev has also indicated this coercion path may be re-introduced.) I was able to fix these in a matter of minutes, and then my tests ran, and passed without any changes. Analysis STHcoerce worked about how I expect STHv5 will work _if_ _every_ _file_ were declared in strict_types mode. In other words, it uncovered errors in calling both userland and internal functions. Userland typehints worked as I expected, with floats using fractional values not casting to integers. ### Wrap Up STHcoerce was actually far more strict than I found strict_types mode to be in STHv5. The reason is that it's a single, non-optional mode. This poses a potential challenge to migration, as noted in my problems using PHPUnit (Yes, I WILL be sending patches their way soon!): method calls and arguments that previously worked because of how PHP juggles types often do not work, particularly when going from boolean to other scalar values. However, the patch does what I'd expect in terms of preventing operations that would result in either data loss or data additions, all of which can have unexpected side effects if you don't understand the casting rules currently. The flip side to this is that you do not need to make any changes to your code in order to locate and fix errors. What this means from a library/framework author perspective is that, if the STHcoerce patch is merged, I can test against PHP 7, make fixes, and my code is not only forward-compatible, but also backwards to the various PHP 5 versions I might already be supporting — and that code now benefits from being more correct. Because STHv5 is opt-in only, the only way to see similar type errors is to somehow automate the addition of the strict_types declaration to all files in your project. While it can be done with tools like
Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
Hey:
On Fri, Feb 27, 2015 at 10:06 AM, François Laupretre franc...@php.net wrote:
De : Matthew Weier O'Phinney [mailto:matt...@zend.com]
- PHPUnit passes a boolean false to `debug_backtrace()`... which is
documented
as expecting an integer! (There are actually several constant values it
accepts, all of which are integer values.) In this case, PHPUnit is relying
on the fact that the engine casts booleans to the integers 0 and 1. (Zeev
has
written to the list already indicating that this coercion path will be
supported in the patch.)
AFAIK, we won't support boolean to integer. IMO, considering Boolean as
integer is a bug and must not be supported.
in a internal developer's view:
bool false === 0, bool true == 1;
maybe this case should be supported?
considering such usage :
if (substr($str, strrpos($str, ':delimiter:')) {
}
this is not a really world usage, I just made it up, this codes is try
to find a last part of a string which is contacted with a dimileter
:delimiter:
like a:delimiter:b, c:dilimiter:d
it works well before, because, if there is no match, it returns false
before.. (which we will think it's '0')
then the whole $str is returned..
but if we don't support bool false - 0?
thanks
- PHPUnit is passing the results of $reflector-getDocComment() blindly to
substr() and preg_match*(). getDocComment() is documented as returning
EITHER
a string OR boolean false. Again, PHPUnit is relying on PHP to cast boolean
false to an empty string. (Zeev has also indicated this coercion path may
be
re-introduced.)
The same as above for bool - string.
I hope you're wrong because I wouldn't like supporting boolean to scalar back
again.
Your test demonstrates this because you found undetected bugs. I am more and
more sure that, what I first said as a joke, will prove true : during the
next years, STH will be used mostly as a debugging tool, proving opposite
arguments were FUD or, at least, phantasm.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
Florian Margaine reduced the problem to the following minimal,
self-contained, reproducing script:
1 ?php
2 class Foo extends Exception
3 {
4 public function __construct()
5 {
6 $this-code = 123;
7 }
8 }
9
10 try
11 {
12 throw new Foo;
13 }
14
15 catch (Exception $e)
16 {
17 assert($e-code === 123);
18 }
The above script works as expected on PHP 5.6.5 but errors out on
PHP 5.6.6:
PHP Fatal error: Cannot access protected property Foo::$code in
/home/sb/exception.php on line 17
PHP Stack trace:
PHP 1. {main}() /home/sb/exception.php:0
I do not see a change in http://php.net/ChangeLog-5.php#5.6.6 that would
explain this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] aes_decrypt() aes_encrypt() (was Re: crypto_something)
On 2/26/15 11:12 AM, Leigh wrote: On 26 February 2015 at 15:37, Tom Worster f...@thefsb.org wrote: I've spoken with Anthony and a couple of others about something in the same vein as the new csprng functions. I think core needs a pair of functions that handles the needs of the 99%. Those functions are. aes_encrypt(string $data, string $key): string aes_decrypt(string $data, string $key): string I have discussed this briefly with Anthony and Nikita, and we haven't reached a consensus on whether AES-n would be determined by key-length (adding complexity for the user), or whether $key should be $passphrase and should have key-stretching performed (this would avoid the case where people pass in hex for a key), in which case we would default to AES-128. The default mode would be CTR An IV would be taken from the csprng random functions, and would be prepended to the result. A strong MAC would be calculated and appended to the result. This doesn't leave any room for interoperability where things are done differently, but it also doesn't leave any room for people to mess it up. I think it's important that when it comes to crypto, we give people the ability to just get it right, without having to know about why something is right or wrong. I welcome any thoughts on this. I agree with this direction and have a few comments. 1. You say it doesn't leave any room for interoperability but I'm not sure I agree. I invite you again to look at the Cryptography lib for Python. The Fernet protocol is published. It implements basically what you are describing above but with a couple of interesting extras: - protocol version number - timestamp, useful for receivers tracking for possible replay I don't see why we couldn't sponsor an effort to encourage adoption of this or some such interoperability protocol. Go to FIG, see if the Rails, Node and Django people are interested, and so fourth... 2. At this stage I think PHP should be thinking beyond AES. There are a number of arguments about phasing out AES that you can find online. Regardless of the merits of these arguments, the demand for newer ciphers is only going to increase. Meanwhile, it's going to be years before anything we discuss here now is mainstream in PHP and more years before that gets upgraded. So I think we may as well have a pluggable backend for algorithm implementations and a means for users to upgrade ciphers, perhaps by introducing new version numbers in the above mentioned protocol from time to time. That said, I'm not in favor of a function that lets users choose among lots of ciphers. I just want an easier way to evolve than introducing new functions, like, idk, threefish_encrypt(). 3. When we did this in the yii\base\Security component we choose to have separate methods for encryptByPassword() and encryptByKey(). The main advantages are: - it makes the API simpler and easier to explain - it encourages the developer to think about the difference - it gives us a soapbox to encourage people to avoid passwords when possible And I encourage PHP to do the same if you want to allow users to do either. Users will sometimes need to encrypt with a password so its best to make it hard to screw up. 4. We included a salt in the message for PBKDF2, and, just to keep the message format the same both ways, used one also for key-based encrypt. Tom Btw: owing to the volume on this list, I am not normally subscribed. I occasionally check activity using nntp but cannot seem to reply that way. In any case, if there's something you want me to see, please send it to my email address. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http
The vote on the pecl_http RFC has been closed, thanks to everyone who participated. The results are 9 in favour and 23 against, so the RFC was declined, which is actually an understatement ;) On 27 02 2015, at 18:19, Pascal MARTIN, AFUP mail...@pascal-martin.fr wrote: Le 26/02/2015 12:28, Michael Wallner a écrit : I forgot to formally declare a voting period, so I’ll do so now. Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do so until then. https://wiki.php.net/rfc/pecl_http#vote Hi, Not many of us at AFUP participated in our discussion about this proposal, but it seems we would be on the -1 side. Basically, even if a good HTTP layer is a good thing, we feel it kind of has its place more in user-land than in PHP itself. Adding this to PHP would mean more maintenance work on PHP itself, but also releases synced with releases of PHP -- which, in the end, is not that interesting for end-users, we think. In any case, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
Hi Lester,
On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine les...@lsces.co.uk wrote:
Please, read the examples again, the current behavior is nothing but
inconsistent:
substr(a, 1) = FALSE
substr(a, -300) =
? That was the case prior to PHP5.2.1
The fixes in 5.2.2 were not commonly accepted but give false for both,
but 5.2.7 and later give false and a which is what was the preferred
result at the time. Unless we are seeing something different, I'm only
seeing a or false for a current output of all your examples.
I meant a, but you are right, it's a bit less inconsistent than I
thought. The current behavior could be defined as if the resulting slice
is so that (start index = end index) and (either start index or end index
is in bound) return the slice, else return FALSE, which is not very useful
but not so bad anyway.
The only real annoyance is that the check is strict on the right bound, so
that:
substr(abcd, 5) = FALSE
while:
substr(abcd, -10, -4) =
That explains one of the E_DEPRECATED triggered by Drupal 7, because when
you want to remove a prefix from a string, you often do:
if (substr($str, 0, strlen($prefix)) {
$str = substr($str, strlen($prefix))
}
But this currently returns FALSE when $str == $prefix.
(Obviously, the most useful behavior would be to return a string in all
cases, like for example, Python.)
Damien
Re: [PHP-DEV] aes_decrypt() aes_encrypt() (was Re: crypto_something)
On 27 February 2015 at 21:14, Tom Worster f...@thefsb.org wrote: 1. You say it doesn't leave any room for interoperability but I'm not sure I agree. I invite you again to look at the Cryptography lib for Python. There are countless applications/services that will do things their own way, and the odds of them using the same structure as any generic implementation is going to be hit and miss. I guess it would have been better if I had said doesn't give any room for flexibility I don't see why we couldn't sponsor an effort to encourage adoption of this or some such interoperability protocol. Go to FIG, see if the Rails, Node and Django people are interested, and so fourth... Feeling pretty pessimistic on this one. Each camp is going to feel that they know best and push for their own way. If we could get a mandate from a group of established and respected cryptographers, maybe :) 2. At this stage I think PHP should be thinking beyond AES. There are a number of arguments about phasing out AES that you can find online. Regardless of the merits of these arguments, the demand for newer ciphers is only going to increase. Meanwhile, it's going to be years before anything we discuss here now is mainstream in PHP and more years before that gets upgraded. So I think we may as well have a pluggable backend for algorithm implementations and a means for users to upgrade ciphers, perhaps by introducing new version numbers in the above mentioned protocol from time to time. That said, I'm not in favor of a function that lets users choose among lots of ciphers. I just want an easier way to evolve than introducing new functions, like, idk, threefish_encrypt(). I hear you. http://marc.info/?l=php-internalsm=142365688004941w=2 Count the number of replies :( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend JIT Open Sourced
On Feb 27, 2015, at 11:36 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, it's possible. But I don't think it's likely. It really smells to me like bias in the testing methodology. (and the lack of an -O3 result is suspicious as well). And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to STDOUT on every single iteration. So you are intentionally not benchmarking the output in the PHP version (you even explicitly call ob_start()) but are benchmarking it in every other version. So in fact, the PHP code does something different than the rest of the code. We actually discussed this at the time of the results. IIRC it really has nothing to do with the output mechanism, etc.. The benchmark does enough iterations and very little output that the impact there is negligible (you can test this yourself to see if I am right but I am pretty sure I am). It is due to the fact that at runtime LLVM can optimize better to the architecture than a static standard gcc build. Constraining gcc with the right architecture dependent switches upfront will also improve the gcc results. Anyway, still pretty cool to see this although it has very little impact (if any) on real world apps ala Magent, WordPress, Drupal, ... I think the important learning is that faster synthetic benchmarks have very little impact on overall application performance. Sure it can have an impact on specific algorithmic pieces of code but that’s the exception not the norm. No doubt there are other ways to write JIT including tracing JITs etc. but I do think we found that we are more bound by I/O and memory/caches than the quality of the machine code as the engine is already quite tight. And with apps consuming more and more Cloud services the I/O bottleneck issue looks grimmer than ever! :) That also comes across consistently in benchmarks of PHP 7 vs. hhvm on real-world apps - you see a JIT and non-JIT platform pretty much head to head on performance and actually on the complex stuff PHP 7 is often faster. Anyway, definitely makes sense to continue to look at these kind of opportunities down the road but PHP 7 is such a huge step-up on real world application performance I think getting that out the door is the biggest possible short-term win when it comes to performance. Looking forward to seeing folks dig into the code and have ideas down the road!! Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend JIT Open Sourced
On Fri, Feb 27, 2015 at 11:53 PM, Anthony Ferrara ircmax...@gmail.com wrote: Zeev, On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, February 27, 2015 10:21 PM To: Dmitry Stogov Cc: Zeev Suraski; Jordi Boggiano; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced Dmitry, Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. Anthony, I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. You could have picked wrong, problematic, inadequate, poor - or a dozen other adjectives that don't literally claim that Dmitry did it intentionally to give an unfair advantage to the PHP implementation (which, just in case anybody's wondering, you also wrote literally, using the word 'intentionally' in the previous sentence. You're not clairvoyant and you have no idea whether Dmitry did it intentionally or not, and the adjectives you used mean negative intent. If you apologize, apologize for real and not with disclaimers that it was taken out of context. It wasn't. And I have no idea why I had to bring it to your attention. If somehow you slipped, you should have fixed it yourself immediately. I had intended it as a remark about the code. Not about him personally, not about you, not about Zend. The presence of the explicit buffering code indicates that it wasn't an accident. Whether it was intentional for extra speed or not, it's still an intentionally different codepath between the rest of the implementations. One that in practice can have non-trivial differences over outputting directly. If you took that as an insult against him, you or Zend, then I'm sorry. I still believe the benchmark is very subtly broken, and hence the results are invalid. I apologized to any insult that may have been misdirected at the person. Please, can we talk about code separately from the person? A good person can produce bad code. That happens. I know, I produce a lot of it. I don't take insult when people call my code bad. And I hope we can call code bad. Because if we can't, we can never grow or move on as people or as a project. So I do apologize to the person. I don't to the code. Anthony PS: Dmitry accepted my apology. Can you please? yes. please. we all have good expectancies anyway. (even if we can't agree on some topics) Dmitry.
RE: [PHP-DEV] Re: Zend JIT Open Sourced
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, February 27, 2015 10:54 PM To: Zeev Suraski Cc: Dmitry Stogov; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced Zeev, On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, February 27, 2015 10:21 PM To: Dmitry Stogov Cc: Zeev Suraski; Jordi Boggiano; PHP Internals Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced Dmitry, Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. Anthony, I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. You could have picked wrong, problematic, inadequate, poor - or a dozen other adjectives that don't literally claim that Dmitry did it intentionally to give an unfair advantage to the PHP implementation (which, just in case anybody's wondering, you also wrote literally, using the word 'intentionally' in the previous sentence. You're not clairvoyant and you have no idea whether Dmitry did it intentionally or not, and the adjectives you used mean negative intent. If you apologize, apologize for real and not with disclaimers that it was taken out of context. It wasn't. And I have no idea why I had to bring it to your attention. If somehow you slipped, you should have fixed it yourself immediately. I had intended it as a remark about the code. Not about him personally I read the email again and again, and I don't see any possibility to read what you wrote in any other way other than blaming the code author (Dmitry) for being sneaky and intentionally faking the test. Sneaky code would either be code that performs something very different from what one would expect (that's not our case here), or code that was written by the author with the intent of doing something sneaky. , not about you, not about Zend. I'm not sure why it even needs to be brought up, this has nothing to do with anybody but Dmitry. Which made it worse in my book, as he's is one of the most honest people I've ever bumped into. PS: Dmitry accepted my apology. Can you please? Yes. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
Am 27.02.2015 um 09:14 schrieb Remi Collet: Hmmm http://3v4l.org/QST64 No clue why PHP 5.6.5 seems to have worked for that reproducing script here earlier. Tried it again and, of course, it also fails with my PHP 5.6.5. Looks the like the reproducing script was not the right one. :-/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
On 27/02/2015 09:06, Sebastian Bergmann wrote: While working on PHPUnit today I noticed one test of its own test suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of this can be found at https://github.com/sebastianbergmann/phpunit/issues/1630 It's actually very weird. As you know I'm monitoring a few key projects and running their test suites every day with the latest 5.4 to 7. The test is not failing here: https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHP56-283/test/case/11819608 Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
I've added the link to the patch
https://github.com/php/php-src/pull/1125/files
Thanks. Dmitry.
On Fri, Feb 27, 2015 at 11:03 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
All,
We've been working in the last few days to test and tune the Coercive STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Can we try the patch ourselves? I would love to run it against some
libraries as well.
Before diving into the results, we did update the RFC
(wiki.php.net/rfc/coercive_sth) - with the most notable difference being
allowing NULL-scalar conversions, for two reasons - it's not uncommon
for
code to use 'null' as a way to denote an empty optional parameter to for
internal functions, and many internal functions seem to rely on that
behavior themselves. It should be possible to alter this behavior in the
future by changing the internal functions to explicitly handle NULL
inputs
as 'please use the default value' - but it's outside the scope of the
RFC.
This RFC trying to simpliy and cleanup the coercison rules, having two
different conversion rules for NULL-scalar
depending on userland or internal is counter-productive and bad. The
behavior you describe as null being
empty value is wide-spread in PHP userland code as well.
In addition, coercion from scalar to boolean is now limited only to
integer - which seems to be the most popular use case; Beforehand,
coercion was also allowed from float and string - but based on feedback
from Mike, we're reconsidering accepting strings again.
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
I agree with Pierre here, it would be super helpful if we had a log in the
RFC of the actual changes that will be happening.
As in Francois original patch this seems to be a game of having 20 changes
and then picking which ones to do and which not.
Now to the tests we ran. The goal was to see what kind of effect the
changes to the internal function APIs had on real world apps with large
codebase. The test methodology was done by placing a debugger breakpoint
on zend_error, to ensure no error gets lost in the ether of settings or
callbacks. Here are the results:
Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
real bug, or at least faulty looking code:
$path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean
false.
return $path;
Drupal admin interface (across the all pages): One new E_DEPRECATED
warning, which again seems to catch a real bug - stripslsahes() operating
on a boolean.
Magento homepage (w/ Magento's huge sample DB): One new E_DEPRECATED
warning, again, seems to be catching a real bug of 'false' being fed as
argument 1 of in json_decode() - which is expecting a string full of json
there.
WordPress homepage: One new E_DEPRECATED warning, again, seems to be
catching a real bug of 'false' being fed as argument 1 of substr().
Zend Framework 2 skeleton app: Zero new E_DEPRECATED warnings.
Symfony ACME app: Zero new E_DEPRECATED warnings (across the app).
I was expecting this, because the rule changes are mostly in regard to not
accepting
invalid input, so what you need to test is all the edge cases.
Say I rely on a validation in count() somewhere in the code to implicitly
validate its an array:
if (count($_GET['filters'])) {
echo Filtering my query;
}
This would work in the happy path case, because i have a filter set. But
maybe
there is some invalid state i can get into and only then the E_DEPRECATED
is produced.
The homepages of popular systems being the essential happy path for a
project, I wouldnt expect many errors to occur.
As I'm sure you know, the above tests invoke a huge number of lines of
code in total, handling filesystem ops, database ops and all sorts of
other things. This is much of the mini test suite that we use to test
PHP's performance and compatibility (e.g. phpng, now PHP 7). So while
this isn't proof that code in the wild isn't going to have more issues -
it's a pretty good initial indication regarding the level of 'breakage'
we
can expect. I'm putting breakage in quotes, as people would have several
years to fix these few issues, before the E_DEPRECATED becomes an error
(or an exception, if the engine exceptions RFC passes).
In terms of the test suite (.phpts), the changes cause approximately 700
extra tests to fail out of 13,700, in comparison to w/o the patch.
However, even though I didn't have a chance to go over all of them, it
seems that the vast majority of the failed tests are tests that were
intentionally designed to cover the exact parameter passing behavior,
rather than real likely real world code
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
Hey: On Fri, Feb 27, 2015 at 4:51 PM, Sebastian Bergmann sebast...@php.net wrote: Am 27.02.2015 um 09:30 schrieb Xinchen Hui: maybe related to your own build? The test in the PHPUnit test suite fails with PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Xdebug v2.3.1, Copyright (c) 2002-2015, by Derick Rethans which comes from Name: php-cli Arch: x86_64 Version : 5.6.6 Release : 1.fc21.remi Size: 13 M Repo: installed From repo : remi Summary : Command-line interface for PHP URL : http://www.php.net/ License : PHP and Zend and BSD Description : The php-cli package contains the command-line interface : executing PHP scripts, /usr/bin/php, and the CGI interface. The test in the PHPUnit test suite does not fail with /usr/local/php-5.6/bin/php -v PHP 5.6.5 (cli) (built: Feb 27 2015 08:26:15) (DEBUG) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies with Xdebug v2.3.0dev, Copyright (c) 2002-2013, by Derick Rethans I noticed different version of xdebug, could you try without it? thanks which I have built from the PHP 5.6.5 tarball. The test in the PHPUnit test suite does not fail with /tmp/php-5.6.6/sapi/cli/php --version PHP 5.6.6 (cli) (built: Feb 27 2015 09:47:36) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies which I have built from the PHP 5.6.6 tarball. Confusing :-/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi Xinchen, On Fri, Feb 27, 2015 at 4:45 PM, Xinchen Hui larue...@php.net wrote: Sorry, but I am confused by the point, do you want to disable include a remote php file or not? if yes, how about with allow_url_fopen? eval(file_get_contents(http://xx/)); thanks My objective is to disable local script/file inclusion by include/require with default usage. We have been added mitigations like allow_url_include=Off and NULL byte restriction for filename. Number of vulnerable applications are reduced, but there are many compare to other languages still. (This RFC removes allow_url_include, but introduce more specific/restrictive API and disables include 'phar://phar_file/script.php'; by default) Regarding eval(file_get_contents(http://xx/)); This kind of operation can be done in other languages also. These codes are not scope of my RFCs. If user specified to do so, it's user's problem. I would like to make PHP as secure as possible with default usage. e.g. Make include($_GET['var') not to read/execute files, but raise proper errors where it is possible as other languages do. This can be done by https://wiki.php.net/rfc/script_only_include and https://wiki.php.net/rfc/allow_url_include If anyone find missing piece, please let me know. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
On 27 February 2015 at 08:20, Leigh lei...@gmail.com wrote: Looking through git blames, this property has been protected for a long time. Possibly related (although not at all sure), Dmitry made some changes to zend_read_property() https://github.com/php/php-src/commit/3e31838d19750d287431d22e9290856ec962fd6a I'm an idiot, this change was in master, not 5.6 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
check xdebug Thanks. Dmitry. On Fri, Feb 27, 2015 at 11:51 AM, Sebastian Bergmann sebast...@php.net wrote: Am 27.02.2015 um 09:30 schrieb Xinchen Hui: maybe related to your own build? The test in the PHPUnit test suite fails with PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Xdebug v2.3.1, Copyright (c) 2002-2015, by Derick Rethans which comes from Name: php-cli Arch: x86_64 Version : 5.6.6 Release : 1.fc21.remi Size: 13 M Repo: installed From repo : remi Summary : Command-line interface for PHP URL : http://www.php.net/ License : PHP and Zend and BSD Description : The php-cli package contains the command-line interface : executing PHP scripts, /usr/bin/php, and the CGI interface. The test in the PHPUnit test suite does not fail with /usr/local/php-5.6/bin/php -v PHP 5.6.5 (cli) (built: Feb 27 2015 08:26:15) (DEBUG) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies with Xdebug v2.3.0dev, Copyright (c) 2002-2013, by Derick Rethans which I have built from the PHP 5.6.5 tarball. The test in the PHPUnit test suite does not fail with /tmp/php-5.6.6/sapi/cli/php --version PHP 5.6.6 (cli) (built: Feb 27 2015 09:47:36) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies which I have built from the PHP 5.6.6 tarball. Confusing :-/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
Am 27.02.2015 um 09:53 schrieb Xinchen Hui: I noticed different version of xdebug, could you try without it? Thank you for bringing Xdebug to my attention. You are right, it appears to be related to Xdebug. Without Xdebug $ php -v PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies the test from PHPUnit's own test suite passes. With Xdebug $ php -v PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Xdebug v2.3.1, Copyright (c) 2002-2015, by Derick Rethans the test from PHPUnit's own test suite fails. Sorry for the noise, time to bug Derick. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A different user perspective on scalar type declarations
On 27/02/15 01:29, François Laupretre wrote: Yes. Same conversion rules : empty string and 0 are false, all the rest is true. For consistency reasons, we can extend the 0 case to accept leading zeroes and leading and trailing blanks, as for a numeric string. Just been checking and yes if a multi-bit binary field is a string of '0's it's false - nothing to process - but any bit set gives true and one scans for the set bit. This is one where the leading zero may affect the numeric conversion, but you can read it as a array of 1's and 0's ... -- 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] [RFC][DISCUSSION] Remove allow_url_include INI
Hi Xinchen, On Fri, Feb 27, 2015 at 4:45 PM, Xinchen Hui larue...@php.net wrote: Sorry, but I am confused by the point, do you want to disable include a remote php file or not? I think the RFC title was misleading. I've changed to Precise URL include control Thank you for your feedback. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 27/02/2015 09:06, Sebastian Bergmann a écrit : While working on PHPUnit today I noticed one test of its own test suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of this can be found at https://github.com/sebastianbergmann/phpunit/issues/1630 Hmmm http://3v4l.org/QST64 Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlTwJ3YACgkQYUppBSnxahgrdgCePafbNJvGFPl5lAp4gQA0xbZj IzwAoI4usnexubkVh7S0HTpIA8cT8B7c =PLcI -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
On 27 February 2015 at 08:06, Sebastian Bergmann sebast...@php.net wrote:
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
Florian Margaine reduced the problem to the following minimal,
self-contained, reproducing script:
1 ?php
2 class Foo extends Exception
3 {
4 public function __construct()
5 {
6 $this-code = 123;
7 }
8 }
9
10 try
11 {
12 throw new Foo;
13 }
14
15 catch (Exception $e)
16 {
17 assert($e-code === 123);
18 }
The above script works as expected on PHP 5.6.5 but errors out on
PHP 5.6.6:
PHP Fatal error: Cannot access protected property Foo::$code in
/home/sb/exception.php on line 17
PHP Stack trace:
PHP 1. {main}() /home/sb/exception.php:0
I do not see a change in http://php.net/ChangeLog-5.php#5.6.6 that would
explain this.
Looking through git blames, this property has been protected for a long time.
Possibly related (although not at all sure), Dmitry made some changes
to zend_read_property()
https://github.com/php/php-src/commit/3e31838d19750d287431d22e9290856ec962fd6a
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
On Fri, Feb 27, 2015 at 9:20 AM, Leigh lei...@gmail.com wrote:
On 27 February 2015 at 08:06, Sebastian Bergmann sebast...@php.net
wrote:
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
Florian Margaine reduced the problem to the following minimal,
self-contained, reproducing script:
1 ?php
2 class Foo extends Exception
3 {
4 public function __construct()
5 {
6 $this-code = 123;
7 }
8 }
9
10 try
11 {
12 throw new Foo;
13 }
14
15 catch (Exception $e)
16 {
17 assert($e-code === 123);
18 }
The above script works as expected on PHP 5.6.5 but errors out on
PHP 5.6.6:
PHP Fatal error: Cannot access protected property Foo::$code in
/home/sb/exception.php on line 17
PHP Stack trace:
PHP 1. {main}() /home/sb/exception.php:0
I do not see a change in http://php.net/ChangeLog-5.php#5.6.6 that
would
explain this.
Looking through git blames, this property has been protected for a long
time.
Possibly related (although not at all sure), Dmitry made some changes
to zend_read_property()
https://github.com/php/php-src/commit/3e31838d19750d287431d22e9290856ec962fd6a
Maybe Related to Reflection Accesibility? I suppose PHPUnit acceses the
private state somehow.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
Hey:
On Fri, Feb 27, 2015 at 4:06 PM, Sebastian Bergmann sebast...@php.net wrote:
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
Florian Margaine reduced the problem to the following minimal,
self-contained, reproducing script:
1 ?php
2 class Foo extends Exception
3 {
4 public function __construct()
5 {
6 $this-code = 123;
7 }
8 }
9
10 try
11 {
12 throw new Foo;
13 }
14
15 catch (Exception $e)
16 {
17 assert($e-code === 123);
18 }
The above script works as expected on PHP 5.6.5 but errors out on
PHP 5.6.6:
PHP Fatal error: Cannot access protected property Foo::$code in
/home/sb/exception.php on line 17
PHP Stack trace:
PHP 1. {main}() /home/sb/exception.php:0
I do not see a change in http://php.net/ChangeLog-5.php#5.6.6 that would
explain this.
maybe related to your own build?
http://3v4l.org/sD8SZ
seems works always consistently same since PHP5
thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6
Am 27.02.2015 um 09:30 schrieb Xinchen Hui: maybe related to your own build? The test in the PHPUnit test suite fails with PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Xdebug v2.3.1, Copyright (c) 2002-2015, by Derick Rethans which comes from Name: php-cli Arch: x86_64 Version : 5.6.6 Release : 1.fc21.remi Size: 13 M Repo: installed From repo : remi Summary : Command-line interface for PHP URL : http://www.php.net/ License : PHP and Zend and BSD Description : The php-cli package contains the command-line interface : executing PHP scripts, /usr/bin/php, and the CGI interface. The test in the PHPUnit test suite does not fail with /usr/local/php-5.6/bin/php -v PHP 5.6.5 (cli) (built: Feb 27 2015 08:26:15) (DEBUG) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies with Xdebug v2.3.0dev, Copyright (c) 2002-2013, by Derick Rethans which I have built from the PHP 5.6.5 tarball. The test in the PHPUnit test suite does not fail with /tmp/php-5.6.6/sapi/cli/php --version PHP 5.6.6 (cli) (built: Feb 27 2015 09:47:36) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies which I have built from the PHP 5.6.6 tarball. Confusing :-/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
- PHPUnit passes a boolean false to `debug_backtrace()`... which is documented as expecting an integer! (There are actually several constant values it accepts, all of which are integer values.) In this case, PHPUnit is relying on the fact that the engine casts booleans to the integers 0 and 1. (Zeev has written to the list already indicating that this coercion path will be supported in the patch.) Matthew, I just wanted to point out that actually, supporting boolean-int coercion is not planned. Converting boolean to integer is actually a very likely scenario where you'd have an outcome that you didn't expect. It's debatable whether sending false to a bitmask is OK or not, but given it's a bitmask, an explicit 0 is a lot more correct. - PHPUnit is passing the results of $reflector-getDocComment() blindly to substr() and preg_match*(). getDocComment() is documented as returning EITHER a string OR boolean false. Again, PHPUnit is relying on PHP to cast boolean false to an empty string. (Zeev has also indicated this coercion path may be re-introduced.) We're looking to re-introduce string-boolean (which will likely be common in database scenarios), but not the other way around - where it's very likely hiding a bug. Virtually all of the boolean-string coercions that were flagged as deprecated by the patch were at the very least suspects of being real world bugs. Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov dmi...@zend.com wrote:
I've added the link to the patch
https://github.com/php/php-src/pull/1125/files
Thanks!
First, the necessary PHPUnit changes (dev-master) to avoid errors:
https://gist.github.com/beberlei/8a33ae940829f1186da2
- Doctrine DBAL testsuite: 8 failures
- Doctrine ORM: Crashes unrelated after half the tests, but has about
30-50% failures like Symfony2
- Symfony2 Testsuite: 6215 failures
- Twig: Tests: 1108, Assertions: 1616, Errors: 125.
Now probably many of the failures are related to few code paths that need
fixing, however I have to find out that and will be a lot of work. But this
is the good PHP code!
For untested or older PHP code (and yes there is alot out there) i now have
to collect the errors in production to find all the occurances. This is
nothing i can just do whenever I want, I need a process to collect and fix
this over time. Now every company needs this process for every project they
have out there. And the typical agency has hundrets/thousands of drupal,
typo3, wordpress installations out there.
Thanks. Dmitry.
On Fri, Feb 27, 2015 at 11:03 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
All,
We've been working in the last few days to test and tune the Coercive
STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Can we try the patch ourselves? I would love to run it against some
libraries as well.
Before diving into the results, we did update the RFC
(wiki.php.net/rfc/coercive_sth) - with the most notable difference
being
allowing NULL-scalar conversions, for two reasons - it's not uncommon
for
code to use 'null' as a way to denote an empty optional parameter to for
internal functions, and many internal functions seem to rely on that
behavior themselves. It should be possible to alter this behavior in
the
future by changing the internal functions to explicitly handle NULL
inputs
as 'please use the default value' - but it's outside the scope of the
RFC.
This RFC trying to simpliy and cleanup the coercison rules, having two
different conversion rules for NULL-scalar
depending on userland or internal is counter-productive and bad. The
behavior you describe as null being
empty value is wide-spread in PHP userland code as well.
In addition, coercion from scalar to boolean is now limited only to
integer - which seems to be the most popular use case; Beforehand,
coercion was also allowed from float and string - but based on feedback
from Mike, we're reconsidering accepting strings again.
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
I agree with Pierre here, it would be super helpful if we had a log in the
RFC of the actual changes that will be happening.
As in Francois original patch this seems to be a game of having 20 changes
and then picking which ones to do and which not.
Now to the tests we ran. The goal was to see what kind of effect the
changes to the internal function APIs had on real world apps with large
codebase. The test methodology was done by placing a debugger
breakpoint
on zend_error, to ensure no error gets lost in the ether of settings or
callbacks. Here are the results:
Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
real bug, or at least faulty looking code:
$path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean
false.
return $path;
Drupal admin interface (across the all pages): One new E_DEPRECATED
warning, which again seems to catch a real bug - stripslsahes()
operating
on a boolean.
Magento homepage (w/ Magento's huge sample DB): One new E_DEPRECATED
warning, again, seems to be catching a real bug of 'false' being fed as
argument 1 of in json_decode() - which is expecting a string full of
json
there.
WordPress homepage: One new E_DEPRECATED warning, again, seems to be
catching a real bug of 'false' being fed as argument 1 of substr().
Zend Framework 2 skeleton app: Zero new E_DEPRECATED warnings.
Symfony ACME app: Zero new E_DEPRECATED warnings (across the app).
I was expecting this, because the rule changes are mostly in regard to not
accepting
invalid input, so what you need to test is all the edge cases.
Say I rely on a validation in count() somewhere in the code to implicitly
validate its an array:
if (count($_GET['filters'])) {
echo Filtering my query;
}
This would work in the happy path case, because i have a filter set. But
maybe
there is some invalid state i can get into and only then the E_DEPRECATED
is produced.
The homepages of popular systems being the essential happy path for a
project, I wouldnt expect many errors to occur.
As I'm sure you know, the
Re: [PHP-DEV] aes_decrypt() aes_encrypt() (was Re: crypto_something)
On 2/27/15, 4:29 PM, Leigh lei...@gmail.com wrote: On 27 February 2015 at 21:14, Tom Worster f...@thefsb.org wrote: I don't see why we couldn't sponsor an effort to encourage adoption of this or some such interoperability protocol. Go to FIG, see if the Rails, Node and Django people are interested, and so fourth... Feeling pretty pessimistic on this one. Each camp is going to feel that they know best and push for their own way. If we could get a mandate from a group of established and respected cryptographers, maybe :) You're thinking on the right lines but you don't need actual cryptographers to win this argument. You just need expert opinion in the use of cryptography. And all the expert opinion needed is in fact available from trusted sources. Let's look at the objections. Say someone is reluctant, defending their design. Two questions: 1. Do you prefer NIH or interpretability? Clearly the interest of your users means that interoperability is the more important of these two. 2. Should your design represent correct use of the crypto primitives or not? Clearly the answer is the former. At this point the argument is won because there are few correct designs and the differences between them are trivial in comparison to interoperability. Thus anyone really digging their heals in is demonstrably either incompetent or not representing the interests of users. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 2/27/15 10:15 AM, Christian Stoller wrote: From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 4:54 PM Hi Christian, On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de wrote: It is not a bug. FALSE as a return value of substr() is the identificator for an error (e.g. invalid arguments), as it is stated in the documentation: [...] It is documented that way and it is not a bug are two very different things. That’s not true. Quoting Wikipedia A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. [1] In this case FALSE is an expected result and it is intended. And as I said other languages are going the same way. Q: How many MicroSoft engineers does it take to change a light bulb? A: None. Bill Gates will just redefine Darkness(TM) as the new industry standard. --Larry Garfield (Sorry, it was just such an obvious opening...) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 2/27/15 9:28 AM, guilhermebla...@gmail.com wrote: +1 on Sebastian's suggestion. =) I volunteer to either update the RFC or create a new one to resolve this once Exceptions in the engine passes (which looks like a reality already to me). Just tell me which approach I should take and I'll happily write the RFC. []s, The RFC is currently in voting, so editing it directly is a no-no. A new, short RFC, please. (Exception implements Throwable, Error implements Throwable sounds good to me. Should we ask about SomeUserspaceClass implements Throwable, or will someone hit me for that?) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Scalar Type Declarations v0.5
On 2/26/15 8:58 AM, Anthony Ferrara wrote: All, I have opened voting on Scalar Type Declarations v0.5. Please cast your vote. https://wiki.php.net/rfc/scalar_type_hints_v5#vote The vote will remain open until March 13th, 2015 or until the date a competing RFC closes voting, whichever is later. Thanks Anthony As both you and Matthew noted in an earlier thread, technically these RFCs are not competing. They're not Apples and Oranges, but more like Gala Apples and Honeycrisp apples. (Now I'm hungry...) We seem to all be agreed about adding scalar type hints, starting from the current weak baseline. Yay, agreement! Can haz? Please? After all these years? One proposal is to then go a step further and add a pedantic (strict) mode that is opt-in by the caller. Pros and Cons. Another proposal is to tighten up the casting rules of PHP itself, with the exact tightening to do still being up for debate. Pros and Cons. Those are not mutually exclusive. They're not quite orthogonal, but they're distinct asks. Personally I rather like both. I think the doom-and-gloom charges against both are greatly over-wrought. And remember that in both cases, *all scalar typing is still opt-in* for user-space code. I would argue absolutely against another ini setting that changes the language behavior. (As in, Holy mother of Vint Cerf censored that censored!) But the more recent samples from Zeev seem promising that the changes are minor enough that we won't need that. The main questions seem to me: 1) For strict mode, is it going to lead to sufficient confusion that people abuse it and do stupid things, and is that risk larger than the potential benefit of easier static analysis (either offline or at compile time) in the future? I am fairly well convinced that if used judiciously a reasonable codebase can leverage strict mode quite heavily without having to throw lots of casts around. What percentage of the PHP using population can be judicious is a debatable point. 2) For pickier coercion, is the tightening of types on core functions (remember, opt-in for user-space code) going to cause sufficient breakage that people are dissuaded from upgrading? This depends heavily on what gets tightened, so we can debate that at length, but I believe it is possible to tighten them enough to be useful without being so tight that it breaks the whole world. Also, keep in mind there's 2 classes of software to think about. The Drupal, Wordpress, Magento, Symfony, etc. developers will update their code to be compatible no matter what. Those core systems will get enough pushback that they'll update one way or another; the developers may throw rotten apples at us (either gala or honeycrisp), but we survived call time pass by reference and the tighter array/string conversion handling in 5.4. Speaking as a Drupal developer: We'll manage. (And those big systems account for, all together, a majority of the lines of PHP actually running in the wild today; to be fair that's mostly Wordpress's doing but still.) Then there's the random script kiddy code, or the code that was perfectly sensible in 2002 that is still running unchanged despite everyone's best judgement. This is the code that scares shared hosts. That code probably won't be moved to a PHP 7 server until 7.4 is out *anyway*, no matter what we do. How badly tighter coercion rules impacts this code is a debatable point, and heavily dependent on what tightening happens. In any case, my point is that we don't need to make it an either/or question. These are both viable, logical extensions to adding basic scalar typing, but not mutually exclusive and no need to turn into camps. If both pass, that's OK. Really, it's OK. Go home and have an apple. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Sebastian Bergmann wrote: I am sorry that I was unable to raise this concern earlier (did not really become aware of the RFC before it was put to the vote), but I would prefer the following: * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine This would be along the lines of what Java does. Note, that a Throwable interface has been already brought up a while ago[1]. [1] http://news.php.net/php.internals/83207 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A different user perspective on scalar type declarations
Hi Zeev, On Fri, Feb 27, 2015 at 2:48 AM, Zeev Suraski z...@zend.com wrote: You may have a point there. As Francois said, he was in favor of allowing leading and trailing spaces. I'll definitely reconsider. If we consider existing code, leading/trailing spaces may need to be allowed. Without considering compatibility issues, leading/trailing spaces should be validated or removed by user input validation/filter code in the first place. I think many users use $ for the end of string data for regex, but it includes newline. To be precise, \z should be used for both PCRE and mbregex. http://perldoc.perl.org/perlre.html Trailing newline is invalid. Leading/trailing spaces may be considered as the same invalid data to be strict. This is what I thought for this. I don't have strong opinion. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Expectations
On Thu, Feb 19, 2015 at 2:09 AM, Joe Watkins pthre...@pthreads.org wrote: The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote This announcement doesn't say when voting will close and the RFC doesn't either. When do you expect voting to close? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference
Hi all, the rfc was declined: - Allow $errstr parameter to be passed by reference: 3 - Allow $errno, $errstr, $errfile, $fileno parameter to be passed by reference: 1 - No, Allow none of the parameter be a reference parameter: 16 Regards Thomas Thomas Bley wrote on 13.02.2015 21:51: Hi all! we'd like to initiate a vote on Allow error_handler callback parameters to be passed by reference: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference We are proposing to enable error_handler callback parameters to be passed by reference to be able to append additional data to error messages. The implementation includes the first four callback parameters to be passed by reference. Thanks to reeze for providing the patch and the tests. The vote has three choices: - Allow $errstr parameter to be passed by reference - Allow $errno, $errstr, $errfile, $fileno parameter to be passed by reference - No, Allow none of the parameter be a reference parameter and closes in 2 weeks from now. Thanks, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A different user perspective on scalar type declarations
Hi Francois, On Fri, Feb 27, 2015 at 10:12 PM, François Laupretre franc...@php.net wrote: If we allow for trailing blanks, we'll allow the same set of chars that is already allowed for leading blanks. I say'blanks' and not 'whitespaces', because here is the list currently allowed as leading blank (with ascii values) : Space (32) , tab (9) , linefeed (10), carriage-return (13), vertical tab (11), and form feed (12). I agree. Emitting E_STRICT and encouraging users to have proper validation/filer is far better. IMHO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 27/02/15 21:14, Damien Tournoud wrote:
Hi Lester,
On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine les...@lsces.co.uk
mailto:les...@lsces.co.uk wrote:
Please, read the examples again, the current behavior is nothing but
inconsistent:
substr(a, 1) = FALSE
substr(a, -300) =
? That was the case prior to PHP5.2.1
The fixes in 5.2.2 were not commonly accepted but give false for both,
but 5.2.7 and later give false and a which is what was the preferred
result at the time. Unless we are seeing something different, I'm only
seeing a or false for a current output of all your examples.
I meant a, but you are right, it's a bit less inconsistent than I
thought. The current behavior could be defined as if the resulting
slice is so that (start index = end index) and (either start index or
end index is in bound) return the slice, else return FALSE, which is
not very useful but not so bad anyway.
The only real annoyance is that the check is strict on the right bound,
so that:
substr(abcd, 5) = FALSE
while:
substr(abcd, -10, -4) =
This is the where the -ve logic stuff was changed. If you try -5 rather
than -4 things swap around versions wise. The 'problem' is where the
actual buffer length goes to 0 and then -ve. There still seem to be a
few edge cases that are not correctly caught, but then currently and
false default to false anyway so there is ONLY a problem if one DOES
remove the weak casting.
That explains one of the E_DEPRECATED triggered by Drupal 7, because
when you want to remove a prefix from a string, you often do:
if (substr($str, 0, strlen($prefix)) {
$str = substr($str, strlen($prefix))
}
But this currently returns FALSE when $str == $prefix.
(Obviously, the most useful behavior would be to return a string in all
cases, like for example, Python.)
If you only want strings then OK, but in that case how would you rework
the drupal problem anyway? Although I'd not start from that if statement
anyway if there is a chance that the $str and $prefix ARE the same
string? The current if statement is what is wrong not the second substr.
if ( strlen($str) strlen($prefix) ) {
$str = substr($str, strlen($prefix))
} else { // nothing left }
But how do you know that the string contains the prefix? Yes the legacy
code base needs tidying up and is full of bugs, but we often just need
to tidy up the logic ...
--
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] [RFC][DISCUSSION] Remove allow_url_include INI
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing allow_url_include INI option. [1]
During Script only include RFC[2] discussion, stream wrapper issue is
raised.
I was thinking this issue as a separate issue, but it seems others are not.
I'm not convinced by the argument that because phar://blah looks like
a URL, allowing it makes allow_url_include broken. Perhaps it would be
better named allow_remote_include, but it corresponds to masking out
your PHP_STREAM_REMOTE flag further down, which is the more important
protection. If you want to be able to disable phar:// access, you could
add something like allow_local_stream_include for that case without
breaking BC.
I'm also not at all clear what you mean by caller and callee
responsibilities; surely the difference is just between a global option
(ini_set()) and a local one (extra argument)? And in what way does
Option #2 require more changes than Option #1, since they both require
the argument to be present whenever a stream wrapper is used?
I do think local options are better than global ini settings in many
cases, but include/require/etc are statements, not functions, so giving
them extra arguments is awkward - some of your examples are wrong in
this regard:
// Redundant brackets make this look like a function, but it's not:
include('phar://phar_file/script.php');
// I can add as many as I like, the parser is just resolving them to a
single string expression:
include'phar://phar_file/script.php';
// This is the actual syntax:
include'phar://phar_file/script.php';
// Implying this for arguments:
include'phar://phar_file/script.php', 'phar://';
// You could explicitly allow a function form of the statements, so
you could parse this:
include(('phar://phar_file/' . $script_name), 'phar://');
// But then you've got a subtle BC break, because the interpretation of
this changes:
include ($foo) . ('.php');
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
