[PHP-DEV] PHP 7.0.0beta2 is available
Hi, The second beta for 7.0.0 was just released and can be downloaded from: https://downloads.php.net/~ab/ The Windows binaries are available at http://windows.php.net/qa/ This release contains fixes for 28 reported bugs and altogether over 200 commits with various improvements. Please test it carefully, and report any bugs in the bug system. The next release by the schedule is going to be tagged on August 4th and released on August 6th. It will be Beta 3. Below is the verification information for the downloads: php-7.0.0beta2.tar.bz2 SHA256 hash: 4a82d2de5365afa471e4c34ef25d80b44813aad9a4ad8a6773e20fa15b72164f PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAABAgAGBQJVrpg6AAoJELyqMOqcDVdjPi0H/RwislrZR7Bd98IR6xdeR3ry aUuQHIn3J+G7ztPWvM1SlCArZ5lrwKrQGDLc4POnIhwVU3WEpwqy44RMNfmDrcFo QVj1/jDDhDYXFvo4i2GfHnfJTrH7khDtq2hVLhgiZpqTiLXuQIygR0NrQ3hK72Yx ke6mRG1ViuxmcKq7gRhA4Qslm8Pxqn5fnw+G8OvNh9W248RtQ1652TRfd6EHKMtm oBVWq0MZTE6EzNe7/HgJGPzaeBnKj4JKmPpd3+h9T1Xvr6pd0sQHGFFmQQQ3OWcC Zs3iqMojtYIr4xROL+djwaUWy35+g0qA4/cNGgyZDpziZAqoJ9eFy3f3Uyz1Q5c= =gvHD -END PGP SIGNATURE- php-7.0.0beta2.tar.gz SHA256 hash: ec3ca8e465551cba43747a8a4db930071e88ed79d628ee6a740396ef1c6bbb7d PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAABAgAGBQJVrphBAAoJELyqMOqcDVdjaVsIAJSTCCCttbS5HEe/h2L/UEGu 8hh7an5ehomuOOMPpQp394LgVF2yBZ5Q5SnAfKDud2Fq7Jrl/8MNt1gRoU2wluiu vx+BcGpKGxGm4zobOjRuuW85mp2ud7eV3b8cXPLrJIN8nSbX7suqFRbyREO0VbJ5 cZBKyYxBqPgHnDCwYpYgg3aBOqRC5hW5EHroZwPz+p2T6gdPMaNnz7FZRbQzXWjI KSSORSVBS1pRIiExst8jdClq6wLKiJOSkzDSYZ9WQDnMBTysr4x4MEXwrjexrCMz Uft6S9lcR4btnFIdAyjD/IBhJWPh4JhxdArdcCjm5ANWncXiXHNTqbGXVYzwo1c= =WAMV -END PGP SIGNATURE- php-7.0.0beta2.tar.xz SHA256 hash: d17e0b9598592f90c717129cb5b453497f86b735bb0b00e53931e03b8ee9 PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAABAgAGBQJVrphFAAoJELyqMOqcDVdjuY4H/RL9hnarCf26CeDLLM3zyahu xdZwsBdmuKYzBJa3/bT3Gg/xIacPR1yPYuUohJgTPM34qvykfBWOxfWDNv/1EpLM puQfMDT/dupAyGX8o9K8M+wMk7XKd7s9K4VafDfzc9rWhHijaaX5384G2XYoxTgF sxg7fCBd4pOJnLQbirbG+jbJsOC3hdPXtIsgQkpMQyocyET7CIdhCgS/DTVSW6nf cVO4mUxnKtCWY489u1L1+ByEExiA8VbgrnsmNwoRjYRpdbc+aSbKaBhxjEPYLDMO mCBTxT2ke+bcgVE57oJx6PjZqNXCEcQTtM1zwVmmf20TuSWUYGFEw/Yj29V+mDI= =j5Z8 -END PGP SIGNATURE- Regards, Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Proposal] Extend support for negative string offsets
François Laupretre wrote:
I need your thoughts on a PR (https://github.com/php/php-src/pull/1431) I am
working on. The subject is to change the way negative string offsets (and
lengths, where applicable) are handled, to make the behavior consistent with
the way they're handled in substr() and substr_replace(). If your return is
positive, I'll write the corresponding RFC.
Implemented so far :
- Support negative string offsets in read mode. Example: $a = $string{-2};
- Support negative string offsets in assignment mode. Example: $string{-2} =
'z';
Generally, I like the idea of being able to specify negative string
offsets. However, I'm usually working with UTF-8 strings, and as such
I'm using string offsets rather seldom.
- strpos() : Accept negative values for the '$offset' argument
- stripos() : Accept negative values for the '$offset' argument
- substr_count(): Accept negative values for the '$offset' and '$length'
parameters (same behavior as in substr()).
That may be useful as well, but what about the respective mbstring and
grapheme functions? At least these should be improved as well, but I'm
not sure if that can be done in an efficient manner.
I also have some questions :
- Should we keep returning NULL on parameter parsing failure, while
documentation only states that false is returned on failure ?
It is documented[1] that:
| If the parameters given to a function are not what it expects, such
| as passing an array where a string is expected, the return value of
| the function is undefined. In this case it will likely return NULL
| but this is just a convention, and cannot be relied upon.
IMHO it's best to stick with the current behavior, and to consider to
raise exceptions sometime in the future.
[1] http://php.net/manual/en/functions.internal.php
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFE to allow dirname($foo, 2)
On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet r...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 See https://bugs.php.net/bug.php?id=70112 As this a very small self-contained change, I don't think it needs a RFE. Feedback welcome Shouldn't you check if you are at the root (or cwd)? currently dirname(/foo/bar, PHP_INT_MAX); hangs -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFE to allow dirname($foo, 2)
On Wed, Jul 22, 2015 at 8:09 AM, flaupre...@free.fr wrote: Hi, De: Remi Collet r...@fedoraproject.org See https://bugs.php.net/bug.php?id=70112 As this a very small self-contained change, I don't think it needs a RFE. +1 for the feature, but not sure it can go to 7.0. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 from me +1 from me on adding it to PHP 7.0.0 as well. And not just to be contrary, I'd like it to be another selling point for upgrading swiftly. :) Though my second vote probably won't count for anything. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Proposal] Extend support for negative string offsets
Hi, De: Christoph Becker cmbecke...@gmx.de That may be useful as well, but what about the respective mbstring and grapheme functions? At least these should be improved as well, but I'm not sure if that can be done in an efficient manner. iconv, mb, and grapheme functions need to be modified the same way as binary string ones. In each case, I will apply the same mechanisms already applied to the the _substr() function, which already support negative offset and length. BTW, it allowed me to discover that NULL is already used as default value for length, at least in grapheme_substr() and mb_substr(). So, it confirms my idea of extending this to every other 'length' parameter. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Resetting wiki.php.net password
Hannes Magnusson wrote on 22/07/2015 23:50: Every blue moon there is a person without VCS account that would like to write an RFC. That must be possible. This may be a naive question, but wouldn't that just be a case of giving them a global account with only wiki karma? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
Hi, you replied to the wrong thread ;)
2015-07-22 19:38 GMT-03:00 S.A.N ua.san.a...@gmail.com:
I am satisfied, the possibility of group declarations, but the that lack:
?php
use App\RestException\ // name RestException, not imported to
current namespace :(
{
Gone,
NotFound,
BadRequest
};
?
Unfortunately have to write so:
?php
use App\RestException;
use App\RestException\{Gone, NotFound, BadRequest};
?
It looks ugly and very strange.
There is nothing strange on it (except, possibly, the trailing `\`
which was discussed to death and voted).
Even if we had no trailing '\' it wouldn't make any sense to import
App\RestException when use App\RestException{Gone, NotFound,
BadRequest}; is used.
My proposition, the imported end name, if end of without slash.
Like this:
?php
use App\RestException
{
Gone,
NotFound,
BadRequest
};
echo RestException::class; // App\RestException
?
Importing from within a namespace is not the same thing as importing a
class. I'd be against it.
My 2 cents: why do you have RestException with Exception suffix
and then don't have the same suffix on the other exception names? This
unpredictable exception hierarchy is the ugly part and subtle
alternative syntax won't make it better, IMMO.
Marcio
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Resetting wiki.php.net password
On Thu, 2015-07-23 at 15:51 +0100, Rowan Collins wrote: Hannes Magnusson wrote on 22/07/2015 23:50: Every blue moon there is a person without VCS account that would like to write an RFC. That must be possible. This may be a naive question, but wouldn't that just be a case of giving them a global account with only wiki karma? This gives (incomplete list) - a @php.net mail address - full bugs.php.net power (except security bugs) - access to all things at master.php.net (this includes moderating notes for the manual) Which is a bit much for somebody where all we know is I want to write an RFC johannes signature.asc Description: This is a digitally signed message part
Re: [PHP-DEV] Re: Resetting wiki.php.net password
Johannes Schlüter wrote on 23/07/2015 16:24: On Thu, 2015-07-23 at 15:51 +0100, Rowan Collins wrote: Hannes Magnusson wrote on 22/07/2015 23:50: Every blue moon there is a person without VCS account that would like to write an RFC. That must be possible. This may be a naive question, but wouldn't that just be a case of giving them a global account with only wiki karma? This gives (incomplete list) - a @php.net mail address - full bugs.php.net power (except security bugs) - access to all things at master.php.net (this includes moderating notes for the manual) Which is a bit much for somebody where all we know is I want to write an RFC johannes Ah, I was right, it was naive. I kind of assumed from the way people talked about it that all those things would require their own separate karma already. I'll stop butting in. ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core functions throwing exceptions in PHP7
On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers m...@sammyk.me wrote: Hello lovely PHP nerds, There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: https://github.com/php/php-src/pull/1397 (main discussion) https://github.com/php/php-src/pull/1398 Currently the random_*() functions will issue a warning and return false if a good source of random cannot be found. This is a potential security hole in the event the RNG fails and returns false which gets evaluated as 0 in a cryptographic context. To prevent this exploit the proposed behavior will throw an Exception when the RNG fails or certain argument validation fails. This also gives the developer a graceful way to fall back to an alternate CSPRNG. Since the core functions in PHP don't throw Exceptions, there is debate on whether or not this change should be implemented. Some say the CSPRNG's should get a special pass since they will be relied on for cryptography. If we can't throw Exceptions, there were suggestions of raising a fatal error if the RNG fails. I think the argument can be boiled down to consistency vs security. We'd love to hear your feedback to decide what we should do in this context. :) Thanks, Sammy Kaye Powers sammyk.me Chicago, IL 60604 How about instead of throwing an instance of Exception, the random_*() functions throw an instance of Error on failure. A subclass of Error, such as SecurityError could also be added. As it is unlikely that the failure of these functions to generate a random value could be handled at runtime, throwing an instance of Error makes the most sense imho. Many internal functions can result in an instance of Error being thrown, particularly with declare(strict_types=1). So those looking for consistency can be satisfied that other internal functions already can behave similarly, and those looking to fail closed can be satisfied that an exception will be thrown if securely generating a random value fails. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Proposal] Extend support for negative string offsets
Hi,
As my previous message seems to have been unnoticed, I send it again.
I need your thoughts on a PR (https://github.com/php/php-src/pull/1431) I am
working on. The subject is to change the way negative string offsets (and
lengths, where applicable) are handled, to make the behavior consistent with
the way they're handled in substr() and substr_replace(). If your return is
positive, I'll write the corresponding RFC.
Implemented so far :
- Support negative string offsets in read mode. Example: $a = $string{-2};
- Support negative string offsets in assignment mode. Example: $string{-2} =
'z';
- strpos() : Accept negative values for the '$offset' argument
- stripos() : Accept negative values for the '$offset' argument
- substr_count(): Accept negative values for the '$offset' and '$length'
parameters (same behavior as in substr()).
The next step is to work on substr_compare(). This one brings a new issue :
as there's no default value for the '$length' param, it is impossible to
perform a case-insensitive comparison without setting an explicit length. If
you want to use the default value, you must compute it (strlen($main_str) -
$offset). My first idea was to use 0 as default value, as this is a quite
useless value. But in order to maximize BC, I will propose to use NULL as
default value for the $length parameter in string functions. This will mean
'up to the end of the string'.
The documentation also needs to be unified because the quality is sometimes
very different between pages for quite similar functions (as an example, see
the difference between http://php.net/manual/en/function.strspn.php and
http://php.net/manual/en/function.strcspn.php).
I also have some questions :
- Should we keep returning NULL on parameter parsing failure, while
documentation only states that false is returned on failure ?
- Would you support unifying error types and messages when offset and/or
length are out-of-bound ?
- In substr_compare(), an offset before the start of the string is silently
converted to 0, while the same condition generates a warning in every other
functions. Which behavior do you prefer ? Silently considering negative
string positions as 0, or issue a warning ?
All of this is creating BC breaks. Most of these changes are additions, so
they just authorize values that would have caused errors in previous
versions. Others give a meaning to useless values (like NULL length). So,
these BC breaks can be considered as limited but they exist. So, what are
your thoughts about including these changes in 7.1 ? (I'd love including
them in 7.0 but I'm afraid it's too late now).
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PCRE JIT stack size limit
Hi Pierre, Pierre Joye wrote: Hi Christoph, There are ways to dymacally increase the stack. Apache's modphp can use the apache config. Fpm, fcgi or cli can change it on windows (afair it is in the doc). It is possible too on Linux with ulimit. An alternative (not a big fan) would be to use setrlimit with an ini setting. Ah, I should have explained better that libpcre's JIT support is implemented as own virtual machine, and libpcre has functions to use a custom stack which is allocated on the heap. If these functions are not used (as it's now in ext/pcre) a fixed 32K on the machine stack are used.[1] Anyhow, it is not possible to change the stack (size) during a call to pcre_exec() (unless, maybe, libpcre would be modified), and it is not possible (to my knowledge) to calculate the required stack size in advance. The required stack size depends on pattern and subject. So basically, we have to call pcre_exec(), and if it fails due to limited stack size, we either fail as well, or we try again. In the latter case we could either use a bigger stack or do without JIT. In the former case we should at least give users a setting to choose the desired stack size, which is quite comparable to pcre.backtrack_limit and pcre.recursion_limit. Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit). That would mean, however, to add yet another ini setting, of which there are already so many. [1] http://www.pcre.org/original/doc/html/pcrejit.html#SEC8 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PCRE JIT stack size limit
Hi Christoph, There are ways to dymacally increase the stack. Apache's modphp can use the apache config. Fpm, fcgi or cli can change it on windows (afair it is in the doc). It is possible too on Linux with ulimit. An alternative (not a big fan) would be to use setrlimit with an ini setting. Cheers, Pierre On Jul 23, 2015 2:07 PM, Christoph Becker cmbecke...@gmx.de wrote: Hi! PHP7 supports PCRE's JIT compilation of patterns by default, which mostly works fine. However, there are issues when the matching exceeds the JIT stack limit, see bug #70110[1]. I'm not sure how to solve this best. Basically, I see two possible solutions: either we fall back to non JIT matching, if pcre_exec() fails with PCRE_ERROR_JIT_STACKLIMIT, or we use a custom JIT stack and make its size a configurable ini setting (similar to pcre.backtrack_limit), and raise E_WARNING if the matching fails due to limited stack size. Thoughts? [1] https://bugs.php.net/bug.php?id=70110 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
2015-07-23 18:10 GMT+03:00 Marcio Almada marcio.w...@gmail.com:
Hi, you replied to the wrong thread ;)
2015-07-22 19:38 GMT-03:00 S.A.N ua.san.a...@gmail.com:
I am satisfied, the possibility of group declarations, but the that lack:
?php
use App\RestException\ // name RestException, not imported to
current namespace :(
{
Gone,
NotFound,
BadRequest
};
?
Unfortunately have to write so:
?php
use App\RestException;
use App\RestException\{Gone, NotFound, BadRequest};
?
It looks ugly and very strange.
There is nothing strange on it (except, possibly, the trailing `\`
which was discussed to death and voted).
Even if we had no trailing '\' it wouldn't make any sense to import
App\RestException when use App\RestException{Gone, NotFound,
BadRequest}; is used.
My proposition, the imported end name, if end of without slash.
Like this:
?php
use App\RestException
{
Gone,
NotFound,
BadRequest
};
echo RestException::class; // App\RestException
?
Importing from within a namespace is not the same thing as importing a
class. I'd be against it.
My 2 cents: why do you have RestException with Exception suffix
and then don't have the same suffix on the other exception names? This
unpredictable exception hierarchy is the ugly part and subtle
alternative syntax won't make it better, IMMO.
Marcio
RestException is the base class for classes Gone, NotFound, BadRequest...
He needed to catch all RestExceptions class.
We do not use suffixes for names of exception classes, simple clear
named classes of exceptions, this is our agreement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFE to allow dirname($foo, 2)
Great suggestion, Remi, I'd love to see this change!
On Wed, Jul 22, 2015 at 7:49 PM, Sara Golemon poll...@php.net wrote:
On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet r...@fedoraproject.org wrote:
See https://bugs.php.net/bug.php?id=70112
I'm not inherently against it, but this really really sounds like a
job for a userspace function.
function dirname_n($path, $n) {
while (($path !== '.') $n--) $path = dirname($path);
return $path;
}
-Sara
Let's assume that we implement this function in userland, either in a Composer
package or more likely in a functions.php file in our project, which Composer or
our project's bootstrap includes for us.
Now, most often, dirname(... dirname(__DIR__) ...) is used in application entry
points during the bootstrapping process. In my experience, it's most commonly
used in order to include an autoloader or some bootstrap file which itself is
responsible for including the autoloader.
In other words, dirname(...) is generally used before we have access to our
includes and classes (no autoloader). Which means, if we were to simply
implement this in userland, we'd have to either write require
dirname(...) in order
to load the dirname_n function every time we need to use it, which would
obviously defeat the object, or conditionally declare the function everywhere
it's needed, which wouldn't be ideal.
Is there some more elegant way this could work in userland which I've missed?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFE to allow dirname($foo, 2)
Hi,
-Original Message-
From: Remi Collet [mailto:r...@fedoraproject.org]
Sent: Thursday, July 23, 2015 7:29 AM
To: PHP Internals internals@lists.php.net
Subject: Re: [PHP-DEV] RFE to allow dirname($foo, 2)
Le 22/07/2015 20:57, Marco Pivetta a écrit :
On 22 July 2015 at 19:49, Sara Golemon poll...@php.net
mailto:poll...@php.net wrote:
On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet r...@fedoraproject.org
mailto:r...@fedoraproject.org wrote:
See https://bugs.php.net/bug.php?id=70112
I'm not inherently against it, but this really really sounds like a
job for a userspace function.
function dirname_n($path, $n) { while (($path !== '.') $n--) $path
= dirname($path); return $path; }http://www.php.net/unsub.php
Indeed. What need is there to add a functionality to a relatively
simple function like this one? What's the actual advantage that cannot
be achieved in userland code?
Legibility and the frequency of the usage of dirname(dirname(...
in various pieces of code.
See
https://github.com/search?q=dirname+__DIR__+language%3Aphpref=searchr
esultstype=Codeutf8=%E2%9C%93
As github search doesn't allow to search for (, I use __dir__ which probably
hides
more usage.
As n is usually 2 or 3, nobody will write a userland function.
IMHO the idea is not doing any harm while solving a real use case. I wouldn't
resist to take it in, especially if there are more useful cases and we can test
the patch early.
One more note is that it's somehow logic coupled with mkdir having the
recursive option. Also it's useful for including the autoloader as no custom
library functions are available yet. A downside could be - it will encourage
people writing a non PHP5 compatible code (or maybe it's not an issue).
Regards
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PCRE JIT stack size limit
Hi! PHP7 supports PCRE's JIT compilation of patterns by default, which mostly works fine. However, there are issues when the matching exceeds the JIT stack limit, see bug #70110[1]. I'm not sure how to solve this best. Basically, I see two possible solutions: either we fall back to non JIT matching, if pcre_exec() fails with PCRE_ERROR_JIT_STACKLIMIT, or we use a custom JIT stack and make its size a configurable ini setting (similar to pcre.backtrack_limit), and raise E_WARNING if the matching fails due to limited stack size. Thoughts? [1] https://bugs.php.net/bug.php?id=70110 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
