Re: [PHP-DEV] Benchmark Results for PHP Master 2015-12-17

vide a good source > of information. The objective of this benchmark is to alert developers accidental performance drop. Even small change may affect performance a lot. This would be good enough for the purpose. IMO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Dev

Re: [PHP-DEV] Travis CI is failing

ls for 5.6, 7.0 and >> master. > > most of them relates to session, Yasuo, could you please have a look into > them? Thank you. I'll fix it now. 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] Travis CI is failing

PHP 5.6 ZTS build. = FAILED TEST SUMMARY - FPM: Test status page [sapi/fpm/tests/010.phpt] = FPM maintainer, please handle this.

Re: [PHP-DEV] Re: PHP 5.6 life cycle

may be an evidence that there are many. +1 for extending PHP 5.6 support. 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] HashDos protection

In practice, we wouldn't have problems with max number of collisions. Max number of collisions resolves the issue for good and we may execute code faster with faster hash. I forgot the number but SipHash is much slower than DJB. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Ru

Re: [PHP-DEV] HashDos protection

ble fatal error, at least E_RECOVERABLE_ERROR, is preferred, IMHO. 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] Re: [RFC] [DISCUSSION] More precise float value

with full patch. Though > please be aware that times are going fast, if you decide to put something 7.0 > related to the vote, be sure the results stand till RC5. Thank you for explanation, Jakub. Ferenc, are you OK with the JSON serialize precision change? i.e. Use PG(serialize_prec

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

Hi Anatol, On Tue, Sep 22, 2015 at 4:35 AM, Anatol Belski <anatol@belski.net> wrote: >> -Original Message- >> From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo >> Ohgaki >> Sent: Sunday, September 20, 2015 11:49 PM >> To: Kalle

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

Hi all, On Fri, Sep 25, 2015 at 7:49 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > No problem. I'll update so that 0 mode is for 7.1. > JSON's is better to use larger precision. So this change is targeted > to 5.6 and 7.0. > > Let me know if you have comments on this. The

[PHP-DEV] new foo()->bar() syntax error : "new" associativity

Hi all, https://bugs.php.net/bug.php?id=70549 It seems this is better to be fixed in near future. Let "new" be associative? Currently, it's syntax error. Was there discussion for this with https://wiki.php.net/rfc/uniform_variable_syntax ? Regards, -- Yasuo Ohgaki yohg...@ohgaki.ne

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

d not loose floating number information, as well as more precise float handling option for PHP 7.0. FYI, var_dump()'s float precision was changed to use serialize_precision as bug fix before. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List

[PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

Hi all, On Fri, Sep 4, 2015 at 9:41 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > IEEE 754 double cannot express exact float values. That said, > float values expressed by json/serialize/var_export/echo/print > are not precise enough in many cases. > > Issues: >

[PHP-DEV] Make strict mode more strict?

string(6) "string" Just an idea. Any comments? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] newbie question

Hi Andrei, On Wed, Sep 16, 2015 at 9:35 AM, Andrei Bernardo Simoni wrote: > HelloIm new in the PHP project and i would like to know where I can start.To > quench my curiosity I wonder which part of the code read the files with > extension .php If you are looking for

[PHP-DEV] Re: Invalid date/time handling - strtotime()

as functionality to handle edge cases > in place, I do not think we should change anything. Thank you for detailed explanation. I'm OK with current design/API. How about add documentation for more precise date/time parsing and handling to strtotime() manual page? One concern is "-00-

[PHP-DEV] Invalid date/time handling - strtotime()

/time. (Do not allow leap second also? Some system may create 60th second) Alternatively, we may be strict - Disallow all edge cases by default. (There may be problem with leap second) Any comments? Reference: https://bugs.php.net/bug.php?id=45647 -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Heads up: merging security patches to 7

It's very helpful and it seems I'm better to wait for unserialize() patch. I'll finish other parts first. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] [DISCUSSION] More precise float value

/suggestions are appreciated! 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] Heads up: merging security patches to 7

Hi Stas, On Wed, Sep 2, 2015 at 7:17 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > There are many fixes regarding unserialize. > We also had many fixes regarding type mismatches. > I suppose many 3rd party modules have same issues. > > How about have a doc for secure PHP

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

er languages. There will be no barrier for our users in the long run. I thought scope variables enabled by default is destructive at first, but Bob clarify they are passed by value. Therefore, it would not be issue. Bob, is there reason not to use the same syntax as Hack "==>"?

Re: [PHP-DEV] Heads up: merging security patches to 7

Hi Stas, There are many fixes regarding unserialize. We also had many fixes regarding type mismatches. I suppose many 3rd party modules have same issues. How about have a doc for secure PHP internal coding? -- Yasuo Ohgaki yohg...@ohgaki.net On Wed, Sep 2, 2015 at 5:55 AM, Stanislav Malyshev

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Hi all, Sorry, I was a bit busy during August. On Wed, Aug 5, 2015 at 5:37 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > I sent work in progress PR for this and updated the RFC. > > https://github.com/php/php-src/pull/1455 > TODO: Add/modify tests. Add 0 mode support for

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

for params. Parser may be extended to parse basic SQL syntax and store syntax tree hash like sql_firewall and compare it to reject SQL injection attacks. Just FYI. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net On Wed, Jul 29, 2015 at 2:33 AM, Matt Tait <matt.t...@gmail.com> wrote: &g

[PHP-DEV] FYI: Linux Foundation CII Draft

Hi all, Some of us may know already. Linux Foundation CII project https://www.coreinfrastructure.org/ released draft badge program. https://github.com/linuxfoundation/cii-best-practices-badge We may consider badge program compliance in the future. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

shooting their own foot, though. I don't have concrete idea now, but PHP may have features help it. -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] libpcre version requirements

prefer to use system's libraries. I suppose question is if PHP supports older systems such as RHEL/CentOS 5 or not. They are used widely. I prefer to support them if it is possible/feasible. Features that are not supported by libs could be documentation issues. IMO. Regards, -- Yasuo Ohgaki yohg

Re: [PHP-DEV] libpcre version requirements

On Wed, Aug 12, 2015 at 4:59 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Distributions prefer to use system's libraries. I suppose question is if PHP supports older systems such as RHEL/CentOS 5 or not. They are used widely. I prefer to support them if it is possible/feasible. Features

[PHP-DEV] Re: zend_string or not?

HI all, On Fri, Aug 7, 2015 at 4:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Is there zend_string usage guideline? I'm wondering if zend_string is used where it is appropriate. Once we release PHP7, adopting zend_string for PHPAPI functions become difficult. (We have to keep legacy API

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

. Even if there is identifier placeholder, SQL keyword remains. So to be perfect, you'll need another place holder for SQL keywords. There is no escaping for SQL keywords and it has to be validation. e.g. ORDER BY {$_GET['order']} Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

On Fri, Aug 7, 2015 at 10:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Even if there is identifier placeholder, SQL keyword remains. So to be perfect, you'll need another place holder for SQL keywords. There is no escaping for SQL keywords and it has to be validation. e.g. ORDER BY {$_GET

[PHP-DEV] zend_string or not?

=PHP_TRUNK Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Hi all, On Fri, Jul 31, 2015 at 4:44 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Thu, Jul 30, 2015 at 6:06 PM, Nikita Popov nikita@gmail.com wrote: On Thu, Jul 30, 2015 at 1:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Thu, Jul 30, 2015 at 7:44 AM, Yasuo Ohgaki yohg

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

assumption, but others. They argue that they would like to fallback to alternative method when error happened. (which I think it's not best way to do) If they don't, E_RECOVERABLE_ERROR is enough. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

when it happened. Anyway, we are better to move errors to exceptions at once and force all modules including 3rd party module to raise exceptions. i.e. Make php_error_docref() raise exceptions. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Hi Nikita, On Thu, Jul 30, 2015 at 6:06 PM, Nikita Popov nikita@gmail.com wrote: On Thu, Jul 30, 2015 at 1:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Thu, Jul 30, 2015 at 7:44 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Thu, Jul 30, 2015 at 1:13 AM, Nikita Popov nikita

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

exception prefered) (Choice: Error/Exception) BTW, I prefer exception, but consistency is important also. My vote will be Yes and Error. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

Hi Niklas, On Sat, Aug 1, 2015 at 7:20 AM, Niklas Keller m...@kelunik.com wrote: 2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net: Hi Niklas, On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller m...@kelunik.com wrote: Using set_error_handler isn't handling errors gracefully. Well

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

Hi Niklas, On Sat, Aug 1, 2015 at 8:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: They should totally be handled. You need to catch the error and throw a defined exception, otherwise your public API will break if you choose to use another internal implementation. Additionally, you seem

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

should be able to handle gracefully if it is possible. That's the reason why I prepared a patch that changes session E_ERROR to E_RECOVERABLE_ERROR. https://github.com/php/php-src/compare/master...yohgaki:master-e_recoverable_error?expand=1 It's inspired by this thread :) Regards, -- Yasuo

Re: [PHP-DEV] json_decode/encode should return full precision values by default

mode for all data exchange functions (json/serialize/var_exrport. Anyone care about WDDX/XML_RPC?) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Hi all, On Thu, Jul 30, 2015 at 7:44 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Thu, Jul 30, 2015 at 1:13 AM, Nikita Popov nikita@gmail.com wrote: Instead of continuing to use serialize_precision, which will produce unnecessarily long outputs for many values, why don't we just switch

Re: [PHP-DEV] json_decode/encode should return full precision values by default

space I've been fixed var_export precision issue as a bug. [yohgaki@dev php-src]$ git show 3cf2682083fc1c8635b02c4c commit 3cf2682083fc1c8635b02c4cf77bdf12c5e5da35 Merge: 5c89d5a 4c45e95 Author: Yasuo Ohgaki yohg...@php.net Date: Tue Oct 29 17:30:58 2013 +0900 Merge branch 'PHP-5.5

Re: [PHP-DEV] json_decode/encode should return full precision values by default

I do not like. Thank you for your feedback. I'll update the RFC and use -1 for it. When I make the patch for this, I'll post new RFC discussion mail. It will take a while. Comments are appreciated. Regards. -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Hi Jakub, On Wed, Jul 29, 2015 at 3:15 AM, Jakub Zelenka bu...@php.net wrote: On Mon, Jul 27, 2015 at 11:17 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Get JSON data from Google maps and store the data using PHP, then users lose last 2 digits of fraction part by default. The value

Re: [PHP-DEV] json_decode/encode should return full precision values by default

On Tue, Jul 28, 2015 at 7:10 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Tue, Jul 28, 2015 at 6:54 AM, Anthony Ferrara ircmax...@gmail.com wrote: On Sun, Jul 26, 2015 at 4:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Jakub, On Mon, Jul 27, 2015 at 3:32 AM, Jakub Zelenka bu

Re: [PHP-DEV] json_decode/encode should return full precision values by default

Hi Anthony, On Tue, Jul 28, 2015 at 6:54 AM, Anthony Ferrara ircmax...@gmail.com wrote: On Sun, Jul 26, 2015 at 4:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Jakub, On Mon, Jul 27, 2015 at 3:32 AM, Jakub Zelenka bu...@php.net wrote: I don't think that this is a bug. Your example

Re: [PHP-DEV] json_decode/encode should return full precision values by default

precision setting is for, as far as I can see. JSON is var exporter/importer like serialize/var_export. Both of serialize/var_export uses PG(serialize_precision), what's the point of _lose_ / _destroy_ original values while PHP could keep more precise values than now? Regards, -- Yasuo Ohgaki yohg

Re: [PHP-DEV] json_decode/encode should return full precision values by default

who don't care for precise data handling wouldn't care for more precise data handling, do they? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] json_decode/encode should return full precision values by default

think this change should be provided as bug fix. Any comments? -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] Re: json_decode/encode should return full precision values by default

Hi all, Created bug report for this issue. https://bugs.php.net/bug.php?id=70137 -- Yasuo Ohgaki yohg...@ohgaki.net On Sun, Jul 26, 2015 at 7:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I had to work with Google Map API and need to handle values precisely. Fortunately, it seems

[PHP-DEV] Re: [PHP-CVS] com php-src: Change E_ERROR and some E_WARNING to E_RECOVERABLE_ERROR.: ext/session/mod_user.c ext/session/mod_user_class.c ext/session/session.c ext/session/tests/bug60860.php

. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

. :) I prefer exception rather than error. However, I would not like to see exception in some functions. It's whether we use exception for builtin functions or not. I understand the risk, but users should handle all errors properly to be secure anyway. Regards, -- Yasuo Ohgaki yohg

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

Hi Scott, On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Sammy, On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers m...@sammyk.me wrote: There are two open PR's for PHP7 to modify

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

function raise exception and the other raise error. It's should be avoided inconsistency. IMHO. If we are going to adopt exception for functions, it would be better to have switch that convert all errors to exceptions. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] Change session module's E_ERROR to E_RECOVERABLE_ERROR

Hi all, Session module's E_ERROR could be E_RECOVERABLE_ERROR. http://lxr.php.net/search?q=E_ERRORdefs=refs=path=ext%2Fsessionhist=project=PHP_TRUNK Any comments changing the error? -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

for in the long run. We may deprecate/remove the switch 10 years later or more. BTW, I'm thinking to have ModulenameException/ModulenameFunctionException or like rather than simply calling/converting errors to ErrorException when exception is enabled for functions. Regards, -- Yasuo Ohgaki yohg

[PHP-DEV] PHP_INT_MIN is not defined?

Hi all, I noticed PHP_INT_MIN is not defined http://3v4l.org/QBavX while it is described in the manual. http://php.net/manual/en/reserved.constants.php What is going on?? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] Re: PHP_INT_MIN is not defined?

On Wed, Jul 8, 2015 at 12:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: while it is described in the manual. http://php.net/manual/en/reserved.constants.php What is going on?? Oops. It says it's from PHP 7.0.0. Please disregard the mail. -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Headsup: PHP7 feature freeze

Hi Anatol, On Mon, Jun 29, 2015 at 10:19 PM, Anatol Belski anatol@belski.net wrote: -Original Message- From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki Sent: Friday, June 26, 2015 1:58 PM To: Hannes Magnusson Cc: Kalle Sommer Nielsen; Internals

Re: [PHP-DEV] Headsup: PHP7 feature freeze

Hi all, On Fri, Jun 26, 2015 at 12:56 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Hannes, On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented

Re: [PHP-DEV] Headsup: PHP7 feature freeze

On Fri, Jun 26, 2015 at 8:57 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I don't think session internal names do not have to be changed. I meant I think session internal names do not have to be changed. I don't mind at all cleanup them. -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Headsup: PHP7 feature freeze

aharvey parametermemcached/parameter). I think this should be reverted. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Headsup: PHP7 feature freeze

Hi Hannes, On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php Rename discussion

Re: [PHP-DEV] Headsup: PHP7 feature freeze

they have to do is define copy of create_sid() method and compatibility is kept. Any comments? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

Hi all, On Wed, Jun 24, 2015 at 12:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Jun 24, 2015 at 12:05 PM, Juan Basso jrba...@gmail.com wrote: Did you test the performance impact on strings? Since you changed how it works the impact can be positive and maybe worth to make the method

Re: [PHP-DEV] Move to Fast ZPP?

Hi Dmitry, On Wed, Jun 24, 2015 at 7:04 PM, Dmitry Stogov dmi...@zend.com wrote: We should NOT use it everywhere. It'll lead to code bloat. OK. Thank you. I'll use it only for functions called many times. e.g. pg_fetch_*(). Should I use #ifndef FAST_ZPP? Regards, -- Yasuo Ohgaki yohg

Re: [PHP-DEV] Move to Fast ZPP?

Hi Ferenc, On Wed, Jun 24, 2015 at 7:29 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Jun 24, 2015 at 12:21 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Ferenc, On Wed, Jun 24, 2015 at 6:21 PM, Ferenc Kovacs tyr...@gmail.com wrote: it was meant as a performance optimization

Re: [PHP-DEV] Move to Fast ZPP?

called many times. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

Hi Andrey, On Wed, Jun 24, 2015 at 6:20 PM, Andrey Andreev n...@devilix.net wrote: On Wed, Jun 24, 2015 at 5:49 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Xinchen, On Wed, Jun 24, 2015 at 11:42 AM, Xinchen Hui larue...@php.net wrote: and for the age usage you replied in github, I

Re: [PHP-DEV] Optimizing php_html_entities()

Hi Anthony, I got it. On Wed, Jun 24, 2015 at 6:41 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Jun 24, 2015 at 12:21 AM, Anthony Ferrara ircmax...@gmail.com wrote: In addition, this breaks the contract, specifically when using scalar types. Because you're no longer going to error

Re: [PHP-DEV] Optimizing php_html_entities()

of JavaScript injections. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

as string:string). What do you mean by break the contract. string parameter is not a requirement/contract. htmlspecialchars/htmlentities just converts param to string. The patch does not change anything as you can see it from the phpt results. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

faster. To build secure apps, users MUST escape everything for the context by _default_. Selective escaping is the cause of injection vulnerability especially with language like PHP. Principle is Don't think, escape all (for the context). Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

: 4.4821939468384 [yohgaki@dev github-php-src]$ ./php.new b.php Time: 4.5892491340637 [yohgaki@dev github-php-src]$ ./php.new b.php Time: 4.6097931861877 -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

Hi Anthony, On Wed, Jun 24, 2015 at 12:00 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Jun 24, 2015 at 10:40 AM, Anthony Ferrara ircmax...@gmail.com wrote: IMHO, escape/unescape/encode/decode/conversion function is better to accept any types. HTML template may be separated

[PHP-DEV] Optimizing php_html_entities()

); for ($i = 0; $i LOOP; $i++) { htmlspecialchars(123456790); } echo 'Time: '.(microtime(true) - $start - $loop_time).\n; -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] Move to Fast ZPP?

ZPP now? What about the #ifndef FAST_ZPP? Is this required now? BTW, if we are supposed to use only Fast ZPP, https://github.com/php/php-src/blob/master/README.PARAMETER_PARSING_API should be updated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

Hi Xinchen, On Wed, Jun 24, 2015 at 11:31 AM, Xinchen Hui larue...@php.net wrote: On Wed, Jun 24, 2015 at 8:32 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Xinchen, On Tue, Jun 23, 2015 at 11:33 PM, Xinchen Hui larue...@php.net wrote: But passing an non-string to htmlspecialchars

Re: [PHP-DEV] Re: Typed Arrays in Scalar Types RFC

/ username is tim-bezhashvyly. Note that there is already https://wiki.php.net/rfc/arrayof, which has been declined. I would like to have something similar to JSON Schema Validation. This could be a function unlike arrayof. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Optimizing php_html_entities()

Hi all, On Wed, Jun 24, 2015 at 6:51 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I got it. On Wed, Jun 24, 2015 at 6:41 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Jun 24, 2015 at 12:21 AM, Anthony Ferrara ircmax...@gmail.com wrote: In addition, this breaks the contract

Re: [PHP-DEV] Optimizing php_html_entities()

by this FR. https://bugs.php.net/bug.php?id=69908 So it brings something for us :) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Re: [VOTE] JSON number to string

be the way going forward in my opinion. It requires a lot more codes to make it work (both user and PHP), but it seems it's the only way to retrieve correct raw value. Looking forward the patch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Packed array is not fast?

fast :) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Packed array is not fast?

much better result with packed array.. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Array dereferencing of scalars

Hi Rowan, On Thu, Jun 11, 2015 at 5:59 PM, Rowan Collins rowan.coll...@gmail.com wrote: Yasuo Ohgaki wrote on 11/06/2015 00:50: If PHP should return NULL always against NULL variables, we may be better to reconsider these behavior. [yohgaki@dev Download]$ php ?php $v = NULL; $$v

Re: [PHP-DEV] Array dereferencing of scalars

the underlying structures so that the lexical/conventional limitations on symbol naming are also imposed by mechanisms that let userland directly manipulate the names of symbols (define(), class_alias() etc). +1 It sounds good change to spot possible bugs. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

[PHP-DEV] Packed array is not fast?

. Am I doing something wrong? HHVM seems to have optimization margins for hash and loop. -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Migrating PHP classes to built in namespace

Hi Tony, On Thu, Jun 11, 2015 at 4:37 PM, Tony Marston tonymars...@hotmail.com wrote: Yasuo Ohgaki wrote in message news:CAGa2bXZvuqV4Kwru+wUL-bfTb9_tnv=l16reu-+w+uajx4h...@mail.gmail.com... Hi Jakub, On Thu, Jun 11, 2015 at 7:43 AM, Jakub Kubícek kelerest...@gmail.com wrote

Re: [PHP-DEV] [VOTE] JSON number to string

-schema.org/latest/json-schema-validation.html#anchor5 Those who do not care rounding errors/etc, they can use default behavior. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] [VOTE] JSON number to string

On Wed, Jun 10, 2015 at 7:57 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Jun 10, 2015 at 7:28 PM, Derick Rethans der...@php.net wrote: Hi, The voting is now open: https://wiki.php.net/rfc/json_numeric_as_string#voting FWIW, I voted no to all of them because (as you even say

Re: [PHP-DEV] [VOTE] JSON number to string

, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Re: PHP-7.0.0 branch

filter. I cannot find it in my local mailbox :( Anyway I got it. Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Array dereferencing of scalars

. In PHP, NULL is treated as 0/false by its context. It's simpler if we get rid of the behavior altogether. IMO. Anyway, removing undefined behavior from other types may be good enough so I don't insist. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Migrating PHP classes to built in namespace

. For long term PHP evolution, having ability to import some namespace into root namespace is great feature. i.e. API/Module version up. We can provide both old and new during migration. Use of namespace is better approach because it may give us super clean global namespace also. Regards, -- Yasuo Ohgaki

Re: [PHP-DEV] Array dereferencing of scalars

Hi all, On Thu, Jun 11, 2015 at 7:22 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I agree that NULL is debatable. In PHP, NULL is treated as 0/false by its context. It's simpler if we get rid of the behavior altogether. IMO. If PHP should return NULL always against NULL variables, we may

Re: [PHP-DEV] Re: [VOTE] Throwable Interface

it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Array dereferencing of scalars

are acceptable anymore, since we're past the timeframe. ?php $foo = 42; $foo['bar']; // = NULL This code cannot be right. How about fix this as a simple bug? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Array dereferencing of scalars

Hi Matt, On Tue, Jun 9, 2015 at 7:04 PM, Matt Wilmas php_li...@realplain.com wrote: Hi all, - Original Message - From: Yasuo Ohgaki Sent: Tuesday, June 09, 2015 Hi all, On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev smalys...@gmail.com wrote: Would throwing a notice

Re: [PHP-DEV] Re: PHP-7.0.0 branch

this in the past before we agreed to always push the release branches so if another RM has to take over a release for some reason it is easier to do so). Are we supposed to merge bug fixes to PHP-7.0.0 branch or leave it alone? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

<    3   4   5   6   7   8   9   10   11   12   >