Re: [PHP-DEV] Suggestion

On Aug 31, 2016, at 11:49, Yasuo Ohgaki wrote: > > I remember an argument that "function" is useful to "grep functions". > This is true, but we have tokenizer and tokenizer does better job. > e.g. It excludes functions inside comments. > > It may be time to consider

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

> On Wed, Aug 31, 2016 at 7:49 AM David Walker wrote: > Hi all, > > As of now, the scheduled time the vote is to close, the RFC stands 19-4 > (accepted). Given this is my first solo RFC, I'm not really sure protocol > to go from here. Dmitry does raise that the implementation

[PHP-DEV] Re: [RFC][VOTE]: Implement socket_getaddrinfo family

On Wed, Aug 24, 2016 at 9:26 AM David Walker wrote: > Hi, > > I'd like to open voting on my RFC[1] to implement getaddrinfo(). The RFC > implements 4 new socket extension functions to aid in the calling, > examining, and connect/binding of the addrinfo structure. > > -- > Dave

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Wed, Aug 31, 2016 at 7:49 AM David Walker wrote: > On Wed, Aug 31, 2016 at 7:48 AM David Walker wrote: > >> I too get Dmitry's result. As the left hand side is an error-zval, and >> the right hand is null, it explodes. Yes, the hackish way I try and >>

Re: [PHP-DEV] VCS Account Request: adambaratz

2016-09-01 0:09 GMT+02:00 Adam Baratz : > One note I missed: it probably goes without saying that I'd like write > access to ext/pdo_dblib, but write access to ext/pdo would also help for > work on common unit tests and functionality. +1, Adam have done great work at trying

Re: [PHP-DEV] VCS Account Request: adambaratz

One note I missed: it probably goes without saying that I'd like write access to ext/pdo_dblib, but write access to ext/pdo would also help for work on common unit tests and functionality. On Tue, Aug 30, 2016 at 4:00 PM, Adam Baratz wrote: > Maintain pdo_dblib extension.

[PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

Hi all, On Mon, Aug 15, 2016 at 9:15 AM, Yasuo Ohgaki wrote: > > This RFC is to add functions that are suitable for input validations > for secure coding. IMHO, these additions are mandatory for PHP. > > https://wiki.php.net/rfc/add_validate_functions_to_filter > Vote ends

Re: [PHP-DEV] Suggestion

On Mon, Aug 29, 2016 at 10:22 PM, Arvids Godjuks wrote: > As was said, this was debated a lot. Both sides had valid arguments, but > this should not be taken lightly just because there is no "BC break". There > is such thing as too much syntactic sugar, and PHP is one of

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-08-31

Results for project PHP master, build date 2016-08-31 06:24:31+03:00 commit: abe3ce5 previous commit:2d72fcc revision date: 2016-08-30 18:07:28+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Wed, Aug 31, 2016 at 7:48 AM David Walker wrote: > I too get Dmitry's result. As the left hand side is an error-zval, and > the right hand is null, it explodes. Yes, the hackish way I try and > resolve things was to check opcodes around the current one, which I should >

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

I too get Dmitry's result. As the left hand side is an error-zval, and the right hand is null, it explodes. Yes, the hackish way I try and resolve things was to check opcodes around the current one, which I should have thought in the case of addition wouldn't have been valid. The entire goal of

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On 31.08.2016 at 12:10, Dmitry Stogov wrote: > no. if you would try the proposed PR with this code, you would see: > > > Fatal error: Uncaught Error: Unsupported operand types I get the following behavior against PR #1269: $ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

Ah, thanks, I thought it was silently passing :-) On 31 Aug 2016 12:10 p.m., "Dmitry Stogov" wrote: > no. if you would try the proposed PR with this code, you would see: > > > Fatal error: Uncaught Error: Unsupported operand types > > -- > *From:*

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

no. if you would try the proposed PR with this code, you would see: Fatal error: Uncaught Error: Unsupported operand types From: Marco Pivetta Sent: Wednesday, August 31, 2016 10:10:23 AM To: Dmitry Stogov Cc: Christoph M. Becker; PHP

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

RFC proposes to emit warning, but the provided code throws unrelated "Unsupported operand types" exception. I see, that after few weeks of work, the implementation (just few lines of C code) is still hackish and incomplete. This makes me think that, the feature can't be cleanly implemented,

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

Dmitry Stogov schrieb am Mi., 31. Aug. 2016, 08:37: > I vote NO, because the implementation introduces more problems than > intents to fix. > > For example the following code starts to throw exception: > > > > Array access on null should always throw IMO. BTW, I'm not against

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

Hi Dmitry, On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" wrote: > > I vote NO, because the implementation introduces more problems than intents to fix. > > For example the following code starts to throw exception: > > > Isn't that the point of this RFC? I would expect this code to

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

I vote NO, because the implementation introduces more problems than intents to fix. For example the following code starts to throw exception: BTW, I'm not against the feature, I'm against the implementation. It's just can't be committed in current state. Thanks. Dmitry.