On Jul 25, 2015 3:00 AM, "Benjamin Eberlei" wrote:
>
> Hi everyone,
>
> i started porting an extension today and scimmed the phpng-upgrading file.
> It has some inaccuracies already with changes after the phpng-merge.
>
> However my access rights are not enough for user (beberlei) getting a
"Read
On 24/07/2015 09:21, Xinchen Hui wrote:
Hey:
I made a small PR about changes output of some types name in
debug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/1434
That function desperately needs an updated manual page. The current one
rec
Hi!
> 1. E_WARNING - fail open, possibly cause security problems for the user
> 2. E_ERROR - fail closed, but make graceful handling a pain in the neck
Can't you just catch Error just as you would catch an Exception? Of
course, it's less clean than specialized exception but I don't see why
it's n
Hi!
> I made a small PR about changes output of some types name in
> debug_zval_dump, to make it behavior consistently with var_dump.
> https://github.com/php/php-src/pull/1434
>
> 2 things are changed:
>
> 1. print int instead of long
> 2. print float instead of double.
I think
Hi Anatol,
Anatol Belski wrote:
> Hi Christoph,
>
>> -Original Message-
>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
>> Sent: Saturday, July 25, 2015 12:09 AM
>> To: Anatol Belski ; 'Pierre Joye'
>>
>> Cc: 'PHP internals'
>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>>
>
Hi everyone,
i started porting an extension today and scimmed the phpng-upgrading file.
It has some inaccuracies already with changes after the phpng-merge.
However my access rights are not enough for user (beberlei) getting a "Read
Only" notice. Could I have permission to edit this page?
Also w
Hi!
> On the surface, this sounds like a good thing. Although, I question that
> if a user is not checking $result === false, then will they end up just
> wrapping this in an empty try/catch so their code does not fail? There
> is a mechanism to detect the error now.
True, but not checking for fa
Hi!
> Given that the *engine itself* now throws exceptions, and we have
> bundled extensions which throw exceptions, the blanket ban on exceptions
> "in core functions" seems increasingly out-dated. This particular
I agree. I think once we agreed we want to convert from fatals to
exceptions, we n
Hi Christoph,
> -Original Message-
> From: Christoph Becker [mailto:cmbecke...@gmx.de]
> Sent: Saturday, July 25, 2015 12:09 AM
> To: Anatol Belski ; 'Pierre Joye'
>
> Cc: 'PHP internals'
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>
> Hi Anatol,
>
> Anatol Belski wrote:
>
> >
Hi Anatol,
Anatol Belski wrote:
> This looks like an extremely fragile topic because it depends on how
> much stack is available to an executable. A custom JIT stack can
> behave more stable but cannot be resized. And the main issue is that
> the JIT stack size, machine stack size and ext/pcre ca
Hi Christoph,
> -Original Message-
> From: Christoph Becker [mailto:cmbecke...@gmx.de]
> Sent: Thursday, July 23, 2015 8:47 PM
> To: Pierre Joye
> Cc: PHP internals
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>
> Hi Pierre,
>
> Pierre Joye wrote:
>
> > Hi Christoph,
> >
> > The
On 23.07.2015 at 13:07, Christoph Becker wrote:
> 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 p
On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski wrote:
>
>> On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers 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)
>> http
Hi Internals,
This is the first message from Intel's language optimization team.
We would like to provide the PHP internals developer community
with a daily service which will monitor latest committed patches
performance regressions against well known workloads.
Our aim is to run a multitude of w
On 24.07.2015 at 14:32, David Zuelke wrote:
> On 24.07.2015, at 09:33, Adam Harvey wrote:
>>
>> On 23 July 2015 at 11:47, Christoph Becker wrote:
>>
>>> Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit).
>>> That would mean, however, to add yet another ini setting, of whic
On Jul 24, 2015 3:32 PM, "David Zuelke" wrote:
>
> On 24.07.2015, at 09:33, Adam Harvey wrote:
> >
> > On 23 July 2015 at 11:47, Christoph Becker wrote:
> >
> >> Therefore I tend to prefer a new ini setting (say,
pcre.jitstack_limit).
> >> That would mean, however, to add yet another ini settin
On 24.07.2015, at 09:33, Adam Harvey wrote:
>
> On 23 July 2015 at 11:47, Christoph Becker wrote:
>
>> 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.
>
> I'm not a big
On Jul 24, 2015 11:21 AM, "Xinchen Hui" wrote:
>
> Hey:
>
> I made a small PR about changes output of some types name in
> debug_zval_dump, to make it behavior consistently with var_dump.
> https://github.com/php/php-src/pull/1434
>
> 2 things are changed:
>
> 1. print int instead of l
Christoph Becker wrote:
> Adam Harvey wrote:
>
>> On 23 July 2015 at 11:47, Christoph Becker wrote:
>>
>>> 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.
>>
>> I'm no
Adam Harvey wrote:
> On 23 July 2015 at 11:47, Christoph Becker wrote:
>
>> 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.
>
> I'm not a big fan of that, although it's
Pierre Joye wrote:
> On Jul 23, 2015 9:47 PM, "Christoph Becker" wrote:
>>
>> 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
>> u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 24/07/2015 02:11, Hannes Magnusson a écrit :
> On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> See https://bugs.php.net/bug.php?id=70112
>>
>>
>> As this a very small self-contained ch
Hey:
I made a small PR about changes output of some types name in
debug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/1434
2 things are changed:
1. print int instead of long
2. print float instead of double.
RM and me are worr
On Jul 24, 2015 10:34 AM, "Adam Harvey" wrote:
>
> On 23 July 2015 at 11:47, Christoph Becker wrote:
>
> > 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.
>
> I'm not a
Hello
PHP 5.6.12 RC1 is available for testing.
You can download it from
http://downloads.php.net/~jpauli/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to t
On 23 July 2015 at 11:47, Christoph Becker wrote:
> 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.
I'm not a big fan of that, although it's at least in the spirit of
what
On Jul 23, 2015 9:47 PM, "Christoph Becker" wrote:
>
> 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
27 matches
Mail list logo
