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
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
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 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
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
-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
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
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
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
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
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 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 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
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 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
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
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
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: 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!
> 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!
> 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 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 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!
> 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!
> 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
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
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
27 matches
Mail list logo
