Re: [PHP-DEV] Inline conditional that returns null if falsy

[Albert Casademont]

Another example is when a scalar input needs to be either left null or
converted to a Value Object:

$color = $data['color'] ? new Color($data['color']) : null;

This would become;

$color = $data['color'] ? new Color($data['color']); //the ": null" part is
implicit

It's actually kinda the inverse of the "?:" operator.

As Guilliam said, Twig already implements such behaviour, it's quite handy
when dealing with nullable variables,


On Tue, Feb 23, 2021 at 4:26 PM Chase Peeler  wrote:

> On Tue, Feb 23, 2021 at 9:31 AM Nikita Popov  wrote:
>
> > On Fri, Feb 12, 2021 at 8:25 PM David Rodrigues 
> > wrote:
> >
> > > Hello!
> > >
> > > It is just a suggestion to be discussed.
> > >
> > > A lot of places on my projects I have codes like:
> > >
> > > $companies = $user->companies->count()
> > > ? new Collection($user->companies)
> > > : null;
> > >
> > > So $companies will be null except if the user has companies.
> > >
> > > My suggestion is create some kind of inline conditional to works like
> > that:
> > >
> > > $companies = $user->companies->count() => new
> > Collection($user->companies);
> > >
> > > If the conditional ($user->companies->count()) is true, then will
> return
> > > the value (after =>), else will be null.
> > >
> > > In my current work project, I have more than 100+ occurrences like
> that.
> > >
> > > So some more examples:
> > >
> > > $userCategory ? $userCategory->getTitle() : null
> > > -> It could be optimized to the new nullsafe operator
> > > $userCategory?->getTitle()
> > >
> > > return $languageFirst instanceof LanguageExperience
> > > ? $languageFirst->title : null;
> > > -> This not, with my suggestion we have:
> > > return $languageFirst instanceof LanguageExperience =>
> > > $languageFirst->title;
> > >
> > > The => is just a suggestion, other options using existing keywords is:
> > > return expr() then output();
> > > return expr(): output();
> > >
> > > I do not know if other languages support something like that.
> > >
> > > Thanks!
> > >
> >
> > There's a limited budget for this kind of syntax sugar, and we already
> have
> > ?:, ??, ??=, ?->. I don't think there's space for yet another shorthand
> > conditional syntax.
> >
> >
> I don't really have any strong feelings on this either way, but ?! seems
> like a logical choice if it was to be implemented.
>
>
> > Note that => cannot be used for this purpose, as it is already used for
> > array literals.
> >
> > Regards,
> > Nikita
> >
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Inline conditional that returns null if falsy

[Albert Casademont]

On Tue, Feb 23, 2021 at 6:28 PM Larry Garfield 
wrote:

>
> 1) Please don't top post.
>

Sorry for that!


> 2)
>
> The advantage of ?: over long-ternary is that the part it lets you omit is
> of variable size, and is often verbose (nested array elements).  That's not
> the case here, as the omitted portion is a fixed length short constant
> value (": null").  So the value of the abbreviation is much less.
>

Sure, it's not a big deal having to write the ": null" but it doesn't add
any value


>
> I am also not a fan of null being commonly used, as it is a dangerous
> value.  More often I would not want null if the color were missing but some
> default color value, which would be represented by something other than
> null anyway.  And "falsy" is, as we've been reminded numerous times, a
> dangerous and tricky thing.  (I just had several PRs against one of my OSS
> libraries because it relied on falsy, which had all sorts of incorrect
> failure conditions.)
>

Agreed, it was just the first example that came to my mind, probably not
the best one. A better example would creating UUID VO's from string|null
input, there's little room for a default here.

Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c

[Albert Casademont]

Hi Dmitry,

I compiled it with gcc 4.7.2 and the bench.php performed well. Where did
you find the errors?

Albert

On Wed, Mar 18, 2015 at 12:22 AM, Dmitry Stogov  wrote:

> Please also tell your GCC version.
> We had problems with 4.6.3 and 4.7.0, so we disabled global variables for
> GCC prior 4.8.0.
>
> Thanks. Dmitry.
>
> On Wed, Mar 18, 2015 at 12:36 AM, Dmitry Stogov  wrote:
>
>> Hi Caio,
>>
>> Could you please run "make test" with and without the patch and compare
>> the failed tests.
>> The patch must not add new failures.
>>
>> Thanks. Dmitry.
>>
>> On Tue, Mar 17, 2015 at 10:15 PM, Caio Souza Oliveira <
>> caio.olive...@eldorado.org.br> wrote:
>>
>>> Hello guys!
>>> I’ve included the optimization proposed in [1] on ppc64le machines and I
>>> could get an outstanding performance improvement of about 69% when running
>>> bench.php (from 2.394 sec to 1.640 sec in average). I’ve tested this on
>>> POWER 8 machines. My patch can be seen at [2]
>>>
>>> Thank you!
>>> Caio Souza Oliveira
>>>
>>> [1]
>>> https://github.com/php/php-src/commit/fb4b7069842491eb66272587422a1f61d41eb869
>>> [2] https://github.com/php/php-src/pull/1181
>>>
>>> --
>>> From: Albert Casademont Filella [mailto:albertcasadem...@gmail.com]
>>> Sent: terça-feira, 17 de março de 2015 13:23
>>> To: Gustavo Frederico Temple Pedrosa
>>> Cc: Dmitry Stogov; Ard Biesheuvel; PHP Internals; Leonardo Bianconi;
>>> Caio Souza Oliveira
>>> Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global
>>> register variables if available: Zend/Zend.m4 Zend/zend_execute.c
>>>
>>> Hi Dmitry,
>>> I can confirm a ~10-11% reduction in execution time of the bench.php
>>> from last month build (x64) to today's commit (from 1.154 sec to 1.010).
>>> Amazing job!
>>> Albert
>>>
>>> On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa <
>>> gustavo.pedr...@eldorado.org.br> wrote:
>>> Hi, Dmitry.
>>>
>>> Thank you for contacting us.
>>>
>>> Leonardo and Caio (in CC), they will verify.
>>>
>>> Thank you very much. Temple.
>>>
>>>
>>>
>>>
>>>
>>> From: Dmitry Stogov [mailto:dmi...@zend.com]
>>> Sent: terça-feira, 17 de março de 2015 08:01
>>> To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
>>> Cc: PHP Internals
>>> Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register
>>> variables if available: Zend/Zend.m4 Zend/zend_execute.c
>>>
>>> Hi,
>>> Please consider possibility of using the same optimization for ARM, PPC
>>> and may be other platforms.
>>> On x86(_84) it makes 2-7% speedup.
>>> Only the similar changes in zend_execute.c and Zend.m4 are required to
>>> enable it.
>>> Thanks. Dmitry.
>>>
>>> -- Forwarded message --
>>> From: Dmitry Stogov 
>>> Date: Tue, Mar 17, 2015 at 1:51 PM
>>> Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
>>> available: Zend/Zend.m4 Zend/zend_execute.c
>>> To: php-...@lists.php.net
>>>
>>>
>>> Commit:fb4b7069842491eb66272587422a1f61d41eb869
>>> Author:Dmitry Stogov  Tue, 17 Mar 2015
>>> 13:51:02 +0300
>>> Parents:   92bf4566ea65042b8f84cae7840298ed151a4f7a
>>> Branches:  master
>>>
>>> Link:
>>> http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
>>>
>>> Log:
>>> Enable GCC global register variables if available
>>>
>>> Changed paths:
>>>   M  Zend/Zend.m4
>>>   M  Zend/zend_execute.c
>>>
>>>
>>> Diff:
>>> diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
>>> index 16f2d5f..e12b00d 100644
>>> --- a/Zend/Zend.m4
>>> +++ b/Zend/Zend.m4
>>> @@ -409,3 +409,48 @@ else
>>>  AC_MSG_RESULT(no)
>>>fi
>>>  fi
>>> +
>>> +AC_ARG_ENABLE(gcc-global-regs,
>>> +[  --disable-gcc-global-regs
>>> +  whether to enable GCC global register
>>> variables],[
>>> +  ZEND_GCC_GLOBAL_REGS=$enableval
>>> +],[
>>> +  ZEND_GCC_GLOBAL_REGS=yes
>>> +])
>>> +AC_MSG_CHECKING(for global register variables support)
>>> +if test "$ZEND_GCC_GLOBAL_REGS" != "no"; then
>

Re: [PHP-DEV] password_hash() best practices

[Albert Casademont]

The iteration count is very different because in bcrypt it's not an
iteration count number at all, it's a "cost". And it's kinda exponential: a
hash with a cost of 11 is twice as hard to compute than that of a 10. At
our company we are using a cost of 11 right now, which means a hash is
computed in around 100ms in a Core i7

On Wed, May 6, 2015 at 9:17 PM, Christoph Becker  wrote:

> Leszek Krupinski:
>
> > While I agree that the statement "bcrypt is better than PBKDF2, thus only
> > bcrypt should be used" is difficult to defend,
>
> Well at least the StackExchange thread[1] pointed out by Nikita supports
> the statement.
>
> > I think saying "bcrypt is a
> > homegrown solution, only PBKDF2 is a good way to do it" is also wrong and
> > OP is opinionated.
>
> ACK.
>
> > IMO - docs should describe alternatives, without statements "X is better
> > than Y", but we also should include PBKDF2 as an option for
> password_hash()
> > - PHP7 is (theoretically, apparently) closed for new features, but we
> > should target the next possible version. I'm not sure if we should opt
> for
> > changing the default.
>
> As Nikata has pointed out there is no standardized crypt-compatible
> format for PBKDF2, so it seems to be preferable not to add it to
> password_hash().
>
> > Regarding iteration count: (again, IMO) 1024 is a bit low, but 128000 as
> a
> > default for everyone might be a bit too much.
>
> As I understand it, the iteration count has to be very different for
> bcrypt and PBKDF2 (the latter requiring much more rounds).  Increasing
> the default cost factor of bcrypt from 10 to 11 or 12 seems to be
> reasonable, considering that 10 had be chosen nearly two years ago.
>
> [1]
> <
> http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage
> >
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Alternative PHP tags and strict_types=1

[Albert Casademont]

mmm I guess this is the correct behaviour, <% tags ar now not parsed at all
and behave as plain text. If you run

http://3v4l.org/uDDW3

foo
 wrote:

> Hi!
>
> In php7@20150501, I've noticed that this code 
> produces the expected output [1]:
>
> <% echo 'top'; %>
> 
> But this code  unexpectedly produces the
> strict-must-be-first instruction error:
>
> <% echo 'top'; %>
> 
>
> Am I missing something?  I expected that removing the ASP tags
>  from the language
> would remove them and their contents from tallying as instructions.
>
> Thanks,
> bishop
>
> [1]: The expected output is "<% echo 'top'; %>", not "top".
>

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Add targets to simplify building PHP with FDO (Feedback Directed Optimisation) PHP should be built with the folowing steps:: Makefile.global configure.in

[Albert Casademont]

this is awesome, i'll give it a try with symfony too!

On Tue, May 26, 2015 at 5:24 PM, Rasmus Lerdorf  wrote:

> On 05/26/2015 07:33 AM, Dmitry Stogov wrote:
> > Commit:7dac4d449f72d7eb029aa1a8ee87aaf38e17e1c5
> > Author:Dmitry Stogov  Tue, 26 May 2015
> 17:33:25 +0300
> > Parents:   ca31711625095c2d6e308d7f0fc9d371ad0934d4
> > Branches:  master
> >
> > Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=7dac4d449f72d7eb029aa1a8ee87aaf38e17e1c5
> >
> > Log:
> > Add targets to simplify building PHP with FDO (Feedback Directed
> Optimisation)
> > PHP should be built with the folowing steps:
> >
> > make clean
> > make -j4 prof-gen
> > ; now php should be trained with some scripts
> > ; for example `sapi/cgi/php -T 1000 /var/www/http/wordpress/index.php >
> /dev/null`
> > make prof-clean
> > make -j4 prof-use
> >
> > The "properly" trained build may give up to 10% real performance boost!
> > "Improprly" trained PHP might be even slower.
>
> Whoa, really 10%? I know there is AutoFDO coming in gcc 5.1 and I didn't
> think this was really practical until then. Perhaps it is. I wonder if
> this will spur php-wordpress, php-drupal and php-mediawiki tuned builds?
>
> -Rasmus
>
>

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

[Albert Casademont]

+1 thanks Jakub!

On Wed, Jan 6, 2016 at 6:09 PM, Jakub Zelenka  wrote:

> Hi,
>
> On Wed, Jan 6, 2016 at 3:35 PM, Bishop Bettini  wrote:
>
> > Hi Jakub,
> >
> > On Wed, Jan 6, 2016 at 10:01 AM, Jakub Zelenka  wrote:
> >>
> >> https://wiki.php.net/rfc/openssl_aead
> >
> >
> > I think the API might need to be more generic so that any future cipher
> > modes with different parameters could also be passed in.
> >
> > The reference model I'd suggest is the "context" parameter passed to
> > stream related-functions.  Userland creates a context, then passes the
> > context to the encrypt/decrypt functions. The context is specific to the
> > wrapper and drives specific behavior. Encrypt can add to the context any
> > specific cipher state that needs to be passed along to decrypt.
> >
> > Using this model, the openssl API might look like:
> >
> > $context = openssl_context_create([ 'aead' => [ 'aad' => '...',
> > 'tag_length' => '...' ]]);
> > $ciphertext = openssl_encrypt(
> > $data, $method, $password, $options, $iv,
> > $context // here is the new parameter, encapsulating all cipher
> > specifics
> > );
> >
> > echo $context['aead']['tag']; // populated by openssl_encrypt
> >
> > $plaintext = openssl_decrypt(
> > $ciphertext, $method, $password, $options, $iv,
> > $context // fully-reversible, because all necessary data are in
> context
> > );
> >
> >
> Please see note in https://wiki.php.net/rfc/openssl_aead#rejected_features
> . Any context related features will add a lot to the size of the
> implementation. In this case it would also mean introducing an object with
> dimension handler to the openssl ext which doesn't really match with the
> rest of the extension API. The proposed API is more conformant to the rest
> and the code addition is also limited which is very important from the
> maintenance point of view.
>
> I have got already an extension where you can do all of this context
> related stuff ( see https://github.com/bukka/php-crypto ) but I don't
> think
> that anything like this should be part of the openssl ext. I think we
> should concentrate on adding just the most important features with minimal
> code addition to openssl ext and also concentrate on the fixing the actual
> bugs. Bare in mind that all of this has to be maintained for very long time
> and when you look to the regular contributors to openssl ext, you won't see
> too many people...
>
> To sum it up this is a minimal proposal to add AEAD support to openssl ext.
> Anything context related is out of scope of this RFC.
>
> Cheers
>
> Jakub
>

Re: [PHP-DEV] [RFC][VOTE] OpenSSL AEAD support

[Albert Casademont]

That's great nees thanks!!

On Wednesday, 27 January 2016, Jakub Zelenka  wrote:

> Hi,
>
> On Wed, Jan 20, 2016 at 4:40 PM, Jakub Zelenka  > wrote:
>
> > Hi,
> >
> > The vote is now open:
> >
> > https://wiki.php.net/rfc/openssl_aead#voting
> >
> >
> >
> The voting has ended and the RFC has been accepted with 7 votes for and 4
> against.
>
> I will merge the patch after sorting out another issue with openssl ext
> (errors storing) and possibly doing a bit more testing.
>
> Cheers
>
> Jakub
>

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Albert Casademont]

This is very interesting, thanks!

Would it make sense to also add an INI setting to disable superglobals and
response functions?


On Tue, Feb 11, 2020 at 10:34 AM Jan Schneider  wrote:

>
> Zitat von Paul M. Jones :
>
> > Hi Internals,
> >
> > After a couple of years of incubation, I am happy to offer a second
> > version of this RFC:
> >
> >   https://wiki.php.net/rfc/request_response
> >
> > It proposes an object-oriented approach around request and response
> > functionality already existing in PHP, in order to reduce the
> > global-state problems that come with superglobals and the various
> > response-related functions.
>
> I like this proposal a lot, since it provides a clear, concise
> interface to these commonly uses, yet inconveniant to use, existing
> functions and variables without having to always use a full-featured
> userland library.
> Speaking of interfaces: since you suggest using decoration and
> composition over extension for ServerResponse, I am missing a
> ServerResponseInterface, so that you can easily typehint such userland
> decorators.
>
> --
> Jan Schneider
> The Horde Project
> https://www.horde.org/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Albert Casademont]

On Tue, Feb 11, 2020 at 1:59 PM Reindl Harald (privat) 
wrote:

>
>
> Am 11.02.20 um 13:42 schrieb Albert Casademont:
> > This is very interesting, thanks!
> >
> > Would it make sense to also add an INI setting to disable superglobals
> and
> > response functions?
>
> no because changing basic language behavior that way is not helpful for
> code meant to run everywhere and not stop working just because tomorrow
> someone changed a random ini setting
>

That could be said for all INI settings: yes they can break things if you
touch them without knowing what they do.

I think it might make sense to be able to disable superglobals and response
functions if your codebase is committed to using the new classes, much like
the old "register_globals" did. Why pollute the global namespace if you
don't need them?

Re: [PHP-DEV] [RFC] Mixed type

[Albert Casademont]

As Larry was asking for an example.

The ParameterBag::get() function from Symfony (and others) that allows you
to fetch request params, for example. That's a mixed type that could return
different values, depending on your request body. Yes, I can type for all
possible scalar values + null + array, but that's a bit of a PITA and
phpstan would complain nonetheless, as the return type of theParameterBag
::get() function is "mixed" and we can't change that. Right now we're
annotating "mixed" with a docblock.

So yes, a "mixed" type is greatly appreciated when dealing with user input.

Thanks!

On Mon, Apr 20, 2020 at 6:41 PM Guilliam Xavier 
wrote:

> On Mon, Apr 20, 2020 at 5:17 PM Larry Garfield 
> wrote:
> >
> > With union types and stringable already on the way, I'm not sure what
> other non-hypothetical use cases would still be that fugly that you'd now
> need to fall back to `mixed`.
>
> For instance:
>   - the parameter of [a wrapper around] gettype() or an is_* function
>   - the return of [a generic implementation of]
> ArrayAccess::offsetGet() or Iterator::current(), or of a userland
> array_value_first() or array_value_last() function
>
> To me, especially the return type declaration can be useful to ensure
> that [every code path of] the implementation returns a value.
>
> --
> Guilliam Xavier
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] opcache.no_cache: Opcache optimization without any caching

[Albert Casademont]

Hi tyson,

Thanks for your RFC. As ReactPHP users this is a very welcome change. Right
now we have to enable file_cache only for the optimizations, as there's no
real benefit of the full opcache in long-running CLI apps. Having this
setting would allow us to even stop using file_cache but get the opcache
optimizations. It would be even better if these optimizations moved into
PHP Core.

Thank you!

Albert

On Thu, May 21, 2020 at 4:07 PM tyson andre 
wrote:

> Hi internals,
>
> https://wiki.php.net/rfc/opcache.no_cache has been updated.
> Instead of opcache.no_cache=1, opcache.enable_cache=0 is now used to
> disable caching.
>
> In the RFC, I wrote that opcache_get_status() now includes the following
> new booleans
>
> - `optimizations_enabled`, which is true if any optimization passes will
> get run.
> - `allow_cache`, which will be true if any form of opcode caching is
> enabled.
>   Maybe `cache_opcodes` or `opcode_cache_enabled` would be a better name.
>
> Any thoughts on whether opcache_get_status() should be changed at all here?
> It's probably possible but inconvenient to determine what's being done
> with extension_loaded() and multiple calls to ini_get(),
> and the intended meaning of existing flags such as `opcache_enabled` was
> never documented
> in https://www.php.net/opcache_get_status
>
> Any other thoughts on the RFC?
>
> > > In my opinion, configuration names should never be "in the negative".
> > > Instead of defaulting to opcache.no_cache=0, default to
> opcache.cache=1.
> >
> > ... the setting isn't actually enabling cache, it's allowing cache (i.e.
> opposite of disabling),
> > so making this "opcache.allow_cache" might be the best. I'll probably go
> with that.
> > (similar to allow_url_fopen, allow_url_include)
> >
> > ... `opcache.cache` could be confused with the caching strategy or the
> path to the cache,
> > or being sufficient on its own to enable caching
>
> Thanks,
> - Tyson
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Albert Casademont]

Why use sessions for CSRF Protection? That an be implemented with simple
cookies.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookies

Btw, not sure if this should be in php core though...it's more an
application thing...

On Tue, May 10, 2016 at 2:44 PM, Niklas Keller  wrote:

> Yasuo Ohgaki  schrieb am Di., 10. Mai 2016 12:57:
>
> > Hi Rowan,
> >
> > On Tue, May 10, 2016 at 6:38 PM, Rowan Collins 
> > wrote:
> > > Yasuo Ohgaki wrote on 10/05/2016 04:24:
> > >>
> > >> Hi all,
> > >>
> > >> It's not nice to work on the same code (i.e. session module) for
> > >> multiple RFCs, but time is limited.
> > >>
> > >> I would like to hear from ideas/comments before I write patch for
> this.
> > >> https://wiki.php.net/rfc/automatic_csrf_protection
> > >
> > >
> > > I think rewriting every URL, and erroring if the token on a URL has
> > expired,
> > > will not be useful for most people. What happens if I copy the URL of a
> > page
> > > into an e-mail or Twitter post? As soon as anybody clicks that link,
> > they're
> > > going to get an error raised; maybe it will recover by clearing their
> > > session, causing them to log out unnecessarily; maybe it will refuse to
> > show
> > > the content claiming they're not authenticated. In the worst case,
> > someone
> > > might take my URL and use the CSRF token against me - they have a time
> > > limit, but if the application author relied on this protection, the
> same
> > > token will be valid for any action on the site.
> >
> > To protect all of URLs automatically, all URLs need to have token.
> > That's the reason why all URLs have token. The risk is the same as
> > Trans SID session management.
> >
> > > As described, the feature seems to assume that all pages are potential
> > CSRF
> > > targets, when even an authenticated user on a forum spends most of
> their
> > > time on URLs which retrieve data and have no side effects. As Stas
> > pointed
> > > out, not all content is amenable to rewriting, either, which could lead
> > to a
> > > false sense of security - dare I compare the infamous magic quotes? A
> > good
> > > implementation of CSRF protection has to consider when to generate a
> > token,
> > > when to check it, and what to do on failure - trying to submit a
> comment
> > > with an invalid CSRF token might re-display the comment form with
> > pre-filled
> > > content, for instance - and this proposal doesn't seem to address that.
> > >
> > > I think this is the kind of feature that can only really be addressed
> by
> > an
> > > application framework, which can have greater knowledge of when actions
> > are
> > > being triggered, link tokens to specific actions, and so on.
> >
> > Because of  likelihood of the vulnerability, it's better provide basic
> > infrastructure. IMO. It's possible to give more control to users.
> >
> >  - Specify protected method GET/POST or both.
> >
>
> GET should never require automatic CSRF protection. If you need this,
> you're doing something fundamentally wrong.
>
> The only exception are things like OAuth, but these have to be handled
> manually anyway.
>
>  - Add session_csrf_validate() for manual validation
> >
> > Implementation is simple enough even with these addition. (Added to RFC)
> >
> > I considered to protect whole application while I was writing this RFC
> > draft. Thank you for point this out!
> >
> > 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] [RFC][DISCUSSION] Revisit trailing commas in function arguments

[Albert Casademont]

Revisiting this thread. AFAIK this RFC was never put to vote, right?

On Fri, Oct 16, 2015 at 9:01 PM, Björn Larsson 
wrote:

> Den 2015-10-16 kl. 15:09, skrev Sammy Kaye Powers:
>
>> On Thu, Oct 15, 2015 at 8:28 PM, Marcio Almada 
>> wrote:
>>
>> Hi,
>>>
>>> 2015-10-14 16:25 GMT-03:00 Sammy Kaye Powers :
>>>
 Hello internals friends!

 I'd like to open a discussion on the RFC to allow trailing commas in
 function arguments.

 https://wiki.php.net/rfc/revisit-trailing-comma-function-args

 Discuss! :)

 Thanks,
 Sammy Kaye Powers
 sammyk.me

>>> Sammy, I think this proposal is too narrow. If we are going to bother
>>> to change the language, then let's do it consistently and allow
>>> trailing commas on all lists in the grammar. These are the ones on
>>> mind right now:
>>>
>>> - use declarations
>>> - group use declarations
>>> - function call argument list
>>> - class member lists (both constants and properties)
>>> - argument list declarations
>>> - arrays (already allowed)
>>>
>>> As exemplified in this gist:
>>> https://gist.github.com/marcioAlmada/75f8f1d47da5dcac2e57
>>>
>>> Why? Because it prevents a reality where each PHP minor version
>>> introduces trailing commas in a new different place, hurting code
>>> portability. Because it couldn't get more consistent. And more
>>> importantly: because we would get rid of this discussion about
>>> trailing commas, forever j/k :)
>>>
>>> ty,
>>> Márcio
>>>
>>> Hey Márcio!
>>
>> Thanks for the suggesting "trailing comma all the things" idea.  I can
>> certainly get behind that idea and I think it would offer an even stronger
>> argument than just trailing commas on function args.
>>
>> I'm curious what others think about broadening the scope of the RFC to
>> include all the list grammars in PHP.
>>
>> Well, if there is a wish to broaden the scope maybe the voting
> should be split on each case? Like the remove depr. func. RFC:
> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
>
> r//Björn
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Performance optimization ideas for PHP 7.3

[Albert Casademont]

Hi Nicolas,

Don’t you think the biggest performance upgrade that PHP could bring is a
real application server that could keep the app bootsrapped between
requests, much like php-pm/reactphp/aerys are trying to do?

Best,

Albert

On Thu, 19 Apr 2018 at 16:11, Nicolas Grekas 
wrote:

> Hello internals,
>
> During the last months, I've been working on optimizing Symfony/Twig for
> PHP7.
> I found a few situations where the PHP engine could likely be optimized,
> and where it would benefit real-world apps.
>
> In each case, these might look like micro-optimizations, but they are not
> in hot loops.
> Here are the links to issues I created in the php bug tracker:
>
> - Class constants are slow: they should be inlined at runtime -
> https://bugs.php.net/76178
> - Add array_key_exists() to the list of specialy compiled functions -
> https://bugs.php.net/76148
> - Don't trigger copy-on-write when assigning same value -
> https://bugs.php.net/76150
>
> As a bonus, I also created this one today:
> - Add hrtime() to zend_try_compile_special_func() -
> https://bugs.php.net/76241
>
> It would be awesome if those ideas could be implemented in a future PHP
> version.
> (I'm sorry I don't have the knowledge to do it myself.)
>
> Keep up the good work!
>
> Nicolas
>

Re: [PHP-DEV] Performance optimization ideas for PHP 7.3

[Albert Casademont]

I agree on maybe opening another thread, I'm a contributor to PHP-PM so
yes, we're trying to make things better on that end ;)

On Thu, Apr 19, 2018 at 4:50 PM, Maxime Veber  wrote:

> Hello,
>
> Thank you very much Nicolas for theses detections ! (I'll try maybe my
> first contributions to PHP 😇)
>
> Albert, I think what you are speaking about is another topic. But still
> interesting. You should maybe try to use php pm and see how it works and
> what are the drawbacks to fix so it works nicely. (because they are many as
> I understood by reading the code of php-pm) Also Ocramius is right on the
> problem of memory leaks to fix in libraries, this is something to focus on.
> Another thread would be great (with more ideas to improve the situation).
>
> Maxime
>
> Le jeu. 19 avr. 2018 à 16:41, Albert Casademont <
> albertcasadem...@gmail.com> a écrit :
>
>> Hi Nicolas,
>>
>> Don’t you think the biggest performance upgrade that PHP could bring is a
>> real application server that could keep the app bootsrapped between
>> requests, much like php-pm/reactphp/aerys are trying to do?
>>
>> Best,
>>
>> Albert
>>
>> On Thu, 19 Apr 2018 at 16:11, Nicolas Grekas <
>> nicolas.grekas+...@gmail.com>
>> wrote:
>>
>> > Hello internals,
>> >
>> > During the last months, I've been working on optimizing Symfony/Twig for
>> > PHP7.
>> > I found a few situations where the PHP engine could likely be optimized,
>> > and where it would benefit real-world apps.
>> >
>> > In each case, these might look like micro-optimizations, but they are
>> not
>> > in hot loops.
>> > Here are the links to issues I created in the php bug tracker:
>> >
>> > - Class constants are slow: they should be inlined at runtime -
>> > https://bugs.php.net/76178
>> > - Add array_key_exists() to the list of specialy compiled functions -
>> > https://bugs.php.net/76148
>> > - Don't trigger copy-on-write when assigning same value -
>> > https://bugs.php.net/76150
>> >
>> > As a bonus, I also created this one today:
>> > - Add hrtime() to zend_try_compile_special_func() -
>> > https://bugs.php.net/76241
>> >
>> > It would be awesome if those ideas could be implemented in a future PHP
>> > version.
>> > (I'm sorry I don't have the knowledge to do it myself.)
>> >
>> > Keep up the good work!
>> >
>> > Nicolas
>> >
>>
>

Re: [PHP-DEV] Extension: arbitrary precision decimal arithmetic in PHP 7

[Albert Casademont]

Looks promising! Could it be added to PECL maybe? That would make it easier
for people to test :D

On Sat, 29 Sep 2018 at 17:46, Rudi Theunissen  wrote:

> Actually yes! You mentioned it to me 5 months ago in a thread on Reddit:
>
> https://www.reddit.com/r/PHP/comments/8fpwi4/if_php_had_a_native_decimal_type_would_you_use_it/dy6zon9/
>
> I'll take a close look at GMPi today and compare them objectively. :)
>
> On Sat, Sep 29, 2018 at 7:20 AM Sara Golemon  wrote:
>
> > On Fri, Sep 28, 2018 at 6:06 PM Rudi Theunissen 
> > wrote:
> > > I've been working on adding arbitrary precision decimal support as an
> > > alternative to *bcmath. *I have created an extension based on
> > *mpdecimal*,
> > > which is what Python 3's decimal module is also based on. I haven't
> > > released or broadcast this project yet, because I wanted to discuss the
> > API
> > > and implementation with internals first.
> > >
> > Have you looked at GMPi ? https://github.com/sgolemon/gmpi
> > It's a replacement for GMP (which includes floating point and an OOP
> > interface).
> >
> > -Sara
> >
>

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

[Albert Casademont]

Thank you all!

Is the Perfomance section of the RFC updated?
https://wiki.php.net/rfc/typed_properties_v2#performance would be great to
know now that the patch is final and merged

On Fri, Jan 11, 2019 at 5:45 PM Marco Pivetta  wrote:

> Hi Nikita,
>
> On Fri, Jan 11, 2019 at 5:38 PM Nikita Popov  wrote:
>
> > On Mon, Oct 22, 2018 at 1:58 PM Sebastian Bergmann 
> > wrote:
> >
> > > Am 26.09.2018 um 15:46 schrieb Nikita Popov:
> > > > I'm pleased to announce that the typed properties RFC has been
> accepted
> > > > with 70 votes in favor and one vote against. We will work to finalize
> > and
> > > > merge the implementation in the next few days.
> > >
> > > Any update on when this will be merged? Thanks!
> > >
> >
> > Sorry for the long delay here. I've spent the last week fixing the
> > remaining issues and cleaning up the patch, and...
> >
> > ...Typed properties are now merged into master! [1]
> >
> > It would be great if people could start experimenting with typed
> properties
> > (e.g. by migrating over existing @var annotations and seeing what
> happens).
> > The earlier we find issues in the implementation or semantics, the
> better.
> >
> > Thanks to everyone who worked on this RFC and participated in
> discussions.
> > Special thanks to Bob Weinand who did most of the initial implementation
> > work on this RFC.
> >
> > Regards,
> > Nikita
> >
> > [1]:
> >
> >
> https://github.com/php/php-src/commit/e219ec144ef6682b71e135fd18654ee1bb4676b4
>
>
> Great news! Just in time to ruin the weekend with some OSS work :D
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Re: [PHP-DEV] [RFC] JIT

[Albert Casademont]

Hi all,

This is fantastic news thank you! I was going to ask if JIT would also work
when Opcache is enabled with "opcache.file_cache_only". Our use case is a
ReactPHP app that right now only has Opcache basically for the
optimizations and we do not use the standard shared memory portion. We
believe JIT could improve quite a lot these kinds of "long-running"
processes that can serve multiple requests per-process. Thanks a lot!

Best,



On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  wrote:

> Hi Internals,
>
>
> I'm glad to finally propose including JIT into PHP.
>
>
> https://wiki.php.net/rfc/jit
>
>
> In the current state it may be included both into PHP-8, where we are
> going to continue active improvement, and into PHP-7.4, as an experimental
> feature.
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[Albert Casademont Filella]

HHVM is a FastCGI interface, just like PHP-FPM is, I don't see your point
here!

On Mon, Feb 9, 2015 at 6:40 PM, S.A.N  wrote:

> 2015-02-09 12:41 GMT+02:00 Rowan Collins :
> > Yes, I can see it working well for specialised uses - you can simply not
> use those aspects of the language that don't make sense. But for it to be a
> mainstream part of the language, it needs to play nicely with other parts
> of the language, and that's where I see it being a complex and painful
> change.
> >
>
> The fact that the lack of native application server for PHP is often
> the reason for leaving the PHP developers to other languages and
> technologies.
>
> Let's see what others have in 2015:
>
> Python - WSGI
> Ruby - Rack
> Perl - PSGI
> JavaScript - JSGI
> Hack - HHVM
>
> PHP - No native application server in core.
>
> What discusses the PHP community?
> Remove or not to remove the PHP4 constructors and many other issues
> that do not add competitive ability PHP...
>
> I personally do not blame you :), just expressing his opinion
> developer who wants to use PHP and can use modern app server in core
> PHP.
>
> Thank.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Albert Casademont Filella]

Just a quick side one, there's no way to make compatible calls from mcrypt
to openssl using "rijndael-192" and "rijndael-256" ciphers, a compatibility
layer is almost impossible. Only AES-128/192/256 (which variants of
"rijndael-128") are possible on both extensions.

On Mon, Feb 9, 2015 at 6:47 PM, Pascal MARTIN, AFUP <
mail...@pascal-martin.fr> wrote:

>
> Le 02/02/2015 20:11, Anatol Belski a écrit :
>
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>> voting. Each item is voted separately. The voting ends on 2015-02-09 at
>> 21:00 CET.
>>
>
> Hi,
>
> After discussing this RFC with other people at AFUP (we weren't that many
> to participate in this discussion -- which probably indicates not many of
> us care about keeping those), it seems we would be:
>
>  * +1 to remove all SAPIs listed in this RFC
>  * +1 to remove ext/imap and ext/mcrypt -- some of us would have preferred
> keeping those, but a new major version feels like the right time to drop
> them, if the underlying libraries aren't maintained anymore.
>  * +1 to remove ext/mssql and ext/sybase_ct
>  * and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one.
>
> Thanks
>
> --
> 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] [RFC-Discuss] Scalar Type Declarations v0.5

[Albert Casademont Filella]

Hi Anthony!

Thanks for bringing this up again. I am asking you the same I asked Andrea
2 weeks ago on Twitter: make it a triple option vote please. She didn't
want to do it, hope you do! This way you eliminate the neverending
discussion about weak vs strict, let the votes decide and see who really
prefers weak type hinting only and who prefers the stricter way, both camps
will have an option to vote.

So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
different Yes votes is needed.

Thanks!

Albert

On Wed, Feb 18, 2015 at 9:44 PM, Anthony Ferrara 
wrote:

> Dear Internals,
>
> Since the resignation of Andrea, the mixed-mode type hint (called
> declaration in the proposal) proposal has been left abandoned.
> Considering that the ending votes were 67/34 (66.3%) with several
> no-votes being only due to reasonably minor issues with the proposal,
> I would like to re-propose her RFC with three minor modifications:
>
> 1. declare(strict_types=1) (if used) is required to be the first
> instruction in the file only. No other usages allowed.
> 2. declare(strict_types=1) {} (block mode) is specifically disallowed.
> 3. int typed variables can resolve a parameter type of float So
> calling requiresAFloat(10) will work even in strict mode.
>
> As this topic has and is being discussed to death, I have put a very
> large "discussion points" section:
> https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
>
> I would kindly ask, before replying that you check to see if your
> question is answered in that list.
>
> If it is not, please follow up here and I will update the RFC.
>
> If your question is listed and you feel that it wasn't given proper
> due, please let's discuss that.
>
> https://wiki.php.net/rfc/scalar_type_hints_v5
>
> Considering this proposal is a minor tweak on an already-discussed and
> voted-on proposal, I plan on bringing this RFC to vote 1 week from
> today (on February 25th, 2015).
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

[Albert Casademont Filella]

I like it! That's what I proposed to Anthony (and Andrea before) before
Zeev presented their alternative, to held a double vote on the strict vs
weak feature. It was not met with much enthusiasm, hope they change their
minds with your proposal!

On Mon, Feb 23, 2015 at 5:43 PM, Benjamin Eberlei 
wrote:

> Hello,
>
> with two competing RFCs (has this ever happend before?) we are in an
> interesting spot now, game theoretically. Just letting both RFC authors
> open and close the votes will bias the votes just by nature of who starts
> first.
>
> My (potentially very wrong) armchair analysis of the timeline is (my game
> theory university knowledge is very dusty):
>
> We have 3 types of players, 1 RFC a author, 1 RFC b author, $n voters,
> roughly (subjective opinion) split between STH v0.5, coercive STH and no
> type hinting (40/40/20).
>
> The first vote to end, will get 40% of votes. If we assume that there are
> STH proponents that don't care about the implementation and only want the
> feature, then they will start to switch their vote on the second RFC now,
> pushing it over 66% like Andrea's RFC managed.
>
> The likelihood of the second RFC winning, REGARDLESS which one that is, is
> much higher. So both RFC authors have no incentive to start their vote
> first, delaying the vote.
>
> One solution could be both votes should be parallel. In this case the
> likelihood of both failing is very high, because you cannot vote with a
> preference here, you will vote yes for one and no for the other. In either
> case, if both votes end at exactly the same time, I think this could get
> some ebay sniping vote sswitch behavior.
>
> So the best/fairest option might probably, vote for both combined in a
> single vote. This makes the likelihood of acceptance very high, however it
> will pick one or the other by 50%+1, which might be against the voting RFC.
>
> In any case, funny problem :-)
>
> greetings
> Benjamin
>

Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

[Albert Casademont Filella]

Yep, that's what I suggested but Leigh did see a competitive advantage for
weak-type hints in any case because if strict won we would have weak hints
too if I didn't use the declare option. I can see that point even though it
was not made at all with the intention of favouring weak vs strict, I
really don't care much, I just want them (whichever flavour) for the future
JIT/AOP goodies that we may have.

So yeah, I am again suggesting the same as Dennis! :)


On Wed, Feb 25, 2015 at 12:23 PM, Dennis Birkholz 
wrote:

> Hi all,
>
> Am 25.02.2015 um 10:09 schrieb Zeev Suraski:
> > I think that what Anthony proposed about a week or so ago, of having both
> > votes, and if both pass 2/3 - have another vote to choose between them
> > (where a simple majority wins) - makes the most sense in this uncharted
> > territory.
>
> but that is exactly what Benjamin predicted to fail according to game
> theory. The only way this will work is to vote if some scalar type hints
> should come in with 7.0 (with a 2/3 majority) and then have a 50%+1 vote
> on which of both proposals. Otherwise the chance for either passing 2/3
> majority is virtually zero.
>
> Or you could create a three-way vote, both proposals together need 2/3
> majority over no-votes and the proposals that gets more than the other
> is chosen.
>
> Greets
> Dennis
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] crypto_something

[Albert Casademont Filella]

Please remember that now is just impossible to use AES-GCM with the current
OpenSSL extension API, there is no way to get/set the authentication tag.
With AES-GCM you already get a MAC for free, that should be the default
operation mode.

https://bugs.php.net/bug.php?id=67304

On Thu, Feb 26, 2015 at 5:18 PM, Leigh  wrote:

> On 26 February 2015 at 16:07, Stefan Esser 
> wrote:
> > Hi,
> >
> >> libgcrypt does at least have a maintainer but it's poor
> >> Werner Koch who is so destitute he lives on charity raised
> >> on Kickstarter and has his work cut out just trying to deal
> >> with GPG: http://is.gd/cbHCYO
> >
> > Wow. Just WOW.
> >
> > Are you jealous that thousands of people consider Werner Koch's work
> > valuable and therefore support him building the financial ground to pay
> > full-time maintainers for a software that millions use without even
> > knowing (HINT: package signatures) or are you just a jerk?
> >
> > Unbelievable.
> >
> > Stefan Esser
>
> Woah, hold on there Stefan. I think you may have misinterpreted
> something here. Toms words definitely don't have any negative feeling
> to them, if anything I got the feeling of sympathy, and the "poor
> maintainer" might have to quit one day unless he gets more funding!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c

[Albert Casademont Filella]

Hi Dmitry,

I can confirm a ~10-11% reduction in execution time of the bench.php from
last month build (x64) to today's commit (from 1.154 sec to 1.010). Amazing
job!

Albert

On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa <
gustavo.pedr...@eldorado.org.br> wrote:

> Hi, Dmitry.
>
> Thank you for contacting us.
>
> Leonardo and Caio (in CC), they will verify.
>
> Thank you very much. Temple.
>
>
>
>
>
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: terça-feira, 17 de março de 2015 08:01
> To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
> Cc: PHP Internals
> Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register variables
> if available: Zend/Zend.m4 Zend/zend_execute.c
>
> Hi,
> Please consider possibility of using the same optimization for ARM, PPC
> and may be other platforms.
> On x86(_84) it makes 2-7% speedup.
> Only the similar changes in zend_execute.c and Zend.m4 are required to
> enable it.
> Thanks. Dmitry.
>
> -- Forwarded message --
> From: Dmitry Stogov 
> Date: Tue, Mar 17, 2015 at 1:51 PM
> Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
> available: Zend/Zend.m4 Zend/zend_execute.c
> To: php-...@lists.php.net
>
>
> Commit:fb4b7069842491eb66272587422a1f61d41eb869
> Author:Dmitry Stogov  Tue, 17 Mar 2015
> 13:51:02 +0300
> Parents:   92bf4566ea65042b8f84cae7840298ed151a4f7a
> Branches:  master
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
>
> Log:
> Enable GCC global register variables if available
>
> Changed paths:
>   M  Zend/Zend.m4
>   M  Zend/zend_execute.c
>
>
> Diff:
> diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
> index 16f2d5f..e12b00d 100644
> --- a/Zend/Zend.m4
> +++ b/Zend/Zend.m4
> @@ -409,3 +409,48 @@ else
>  AC_MSG_RESULT(no)
>fi
>  fi
> +
> +AC_ARG_ENABLE(gcc-global-regs,
> +[  --disable-gcc-global-regs
> +  whether to enable GCC global register
> variables],[
> +  ZEND_GCC_GLOBAL_REGS=$enableval
> +],[
> +  ZEND_GCC_GLOBAL_REGS=yes
> +])
> +AC_MSG_CHECKING(for global register variables support)
> +if test "$ZEND_GCC_GLOBAL_REGS" != "no"; then
> +  AC_TRY_COMPILE([
> +  ],[
> +#if defined(__GNUC__) && defined(i386)
> +# define ZEND_VM_FP_GLOBAL_REG "%esi"
> +# define ZEND_VM_IP_GLOBAL_REG "%edi"
> +#elif defined(__GNUC__) && defined(__x86_64__)
> +# define ZEND_VM_FP_GLOBAL_REG "%r14"
> +# define ZEND_VM_IP_GLOBAL_REG "%r15"
> +#else
> +# error "global register variables are not supported"
> +#endif
> +typedef int (*opcode_handler_t)(void);
> +register void *FP  __asm__(ZEND_VM_FP_GLOBAL_REG);
> +register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
> +int emu(const opcode_handler_t *ip, void *fp) {
> +   const opcode_handler_t *orig_ip = IP;
> +   void *orig_fp = FP;
> +   IP = ip;
> +   FP = fp;
> +   while ((*ip)());
> +   FP = orig_fp;
> +   IP = orig_ip;
> +}
> +  ], [
> +ZEND_GCC_GLOBAL_REGS=yes
> +  ], [
> +ZEND_GCC_GLOBAL_REGS=no
> +  ])
> +fi
> +if test "$ZEND_GCC_GLOBAL_REGS" = "yes"; then
> +  AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
> support for global register variables])
> +else
> +  HAVE_GCC_GLOBAL_REGS=no
> +fi
> +AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
> diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
> index b24218a..17e68dc 100644
> --- a/Zend/zend_execute.c
> +++ b/Zend/zend_execute.c
> @@ -2049,7 +2049,7 @@ static zend_always_inline void
> zend_vm_stack_extend_call_frame(zend_execute_data
>  }
>  /* }}} */
>
> -#if HAVE_GCC_GLOBAL_REGS
> +#ifdef HAVE_GCC_GLOBAL_REGS
>  # if defined(__GNUC__) && defined(i386)
>  #  define ZEND_VM_FP_GLOBAL_REG "%esi"
>  #  define ZEND_VM_IP_GLOBAL_REG "%edi"
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>