Re: [PHP-DEV] Memory leak in eval()'d code

On Sat, Jun 29, 2019 at 15:52 Nikita Popov wrote: > On Sat, Jun 29, 2019 at 11:25 PM Benjamin Morel > wrote: > > The leaked memory is an allocated but unused class > entry. We could plug that particular leak -- but I should emphasize that > the current behavior is incorrect and once the key col

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

On Wed, Dec 6, 2017 at 2:32 PM Rowan Collins wrote: > On 06/12/2017 19:49, Nikita Popov wrote: > > Hi internals, > > > > I'd like propose optional support for explicitly marking by-reference > > argument passing at the call-site, in addition to the declaration-site > > > Hi Nikita, > > I approve

Re: [PHP-DEV] [RFC][Post-Discussion]: E_WARNING when using array-index on non valid container

On Wed, May 31, 2017 at 10:16 AM Dan Ackroyd wrote: > Hi David, > > On 11 January 2017 at 15:42, David Walker wrote: > > Joe had requested renewed discussion on the accepted RFC[1] and my > proposed > > PR[2] be brought forward again for implementation discussion, a

Re: [PHP-DEV] generating code from AST

On Mon, Mar 6, 2017 at 22:55 Sebastian Bergmann wrote: > Am 06.03.2017 um 22:40 schrieb Sara Golemon: > > https://github.com/sgolemon/astkit > > There's also https://github.com/nikic/php-ast. > > But wouldn't it be great if PHP 7.2 shipped with a built-in, > enabled-by-default extension for AST o

[PHP-DEV] Re: [RFC][VOTE] - list() reference assignment

On Mon, Feb 6, 2017 at 10:54 AM David Walker wrote: > Hi all, > > Having seen no further discussion I'd like to open the RFC[1] for voting. > Voting will be given just over 2 weeks ending Feb 22nd. RFC has > implementation[2] and language spec change[3] for review. >

[PHP-DEV] [RFC][VOTE] - list() reference assignment

Hi all, Having seen no further discussion I'd like to open the RFC[1] for voting. Voting will be given just over 2 weeks ending Feb 22nd. RFC has implementation[2] and language spec change[3] for review. Thanks! -- Dave [1] - https://wiki.php.net/rfc/list_reference_assignment [2] - https://git

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

On Mon, Jan 30, 2017 at 18:12 Andrea Faulds wrote: > Hi Levi, > > Levi Morrison wrote: > > Here is an example of an existing closure: > > > > function ($x) use ($arr) { > > return $arr[$x]; > > } > > > > This RFC proposes syntax and semantics to simplify this common usage to: > >

[PHP-DEV] Re: [RFC][Discussion] - list() reference syntax

On Wed, Jan 11, 2017 at 8:43 AM David Walker wrote: > [Sorry if this is a second time you get this, but email issues and all] > > Hi All, > > I had mentioned the other day my desire to look at, and attempt > implementation of allowing by-reference assignment within list(

Re: [PHP-DEV] Re: [RFC][Discussion] - list() reference syntax

On Wed, Jan 11, 2017 at 3:15 PM Andrea Faulds wrote: > Regarding the =& open issue in the RFC, I don't think the =& syntax > makes sense to me. The thing on the right-hand side of a list() > assignment is the array, not its values. It makes no difference for the > purposes of assigning from its v

[PHP-DEV] Fwd: [RFC][Discussion] - list() reference syntax

[Sorry if this is a second time you get this, but email issues and all] Hi All, I had mentioned the other day my desire to look at, and attempt implementation of allowing by-reference assignment within list()'s. Andrea had created an RFC for this purpose 2+years ago, but withdrew it due to probl

[PHP-DEV] [RFC][Post-Discussion]: E_WARNING when using array-index on non valid container

[Sorry if this is a second time you get this, but email issues and all] Hi all, Joe had requested renewed discussion on the accepted RFC[1] and my proposed PR[2] be brought forward again for implementation discussion, and to come up with a resolution. The RFC, though accepted, had concerns with

[PHP-DEV] [RFC][Discussion] - list() reference syntax

Hi All, I had mentioned the other day my desire to look at, and attempt implementation of allowing by-reference assignment within list()'s. Andrea had created an RFC for this purpose 2+years ago, but withdrew it due to problems with implementation with the parsing/compiler of PHP 5. I've taken a

[PHP-DEV] Re: Bug 63744 - references in list()

On 12/28/16 6:32 PM, Andrea Faulds wrote: Hi Dave, David Walker wrote: I stumbled upon this bug report (read: feature request) today and took a swing at it thinking it couldn't be that overly complex. But then again it was requested way back in the PHP4 era, so I figured there has to be

Re: [PHP-DEV] [RFC] Interval Comparison

On Sat, Nov 12, 2016 at 9:47 AM Christoph M. Becker wrote: > On 12.11.2016 at 17:21, David Walker wrote: > > > Should > > $a = 1; > > var_dump(1 < $a++ < 3); > > > > (expanded into numbers) be evaluated as: > > 1 < 2 && 2 < 3 -

Re: [PHP-DEV] [RFC] Interval Comparison

On Sat, Nov 12, 2016 at 3:08 AM Lauri Kenttä wrote: > On 2016-11-11 19:03, David Walker wrote: > > > > I took a quick stab at implementing, and had something working for > > constant expressions, but handling something akin to: > > > > $a = 2; > > if (1 &

Re: [PHP-DEV] [RFC] Interval Comparison

On Wed, Nov 9, 2016 at 12:48 PM Fleshgrinder wrote: > On 11/8/2016 10:57 PM, David Walker wrote: > > I don't think that alone allows the chaining of comparisons. I'd have to > > look closer, but it'd seem to me that zend_ast_create_binary_op > > (ZEND_AST_BI

Re: [PHP-DEV] [RFC] Interval Comparison

On Tue, Nov 8, 2016 at 12:34 PM Fleshgrinder wrote: > This requires associativity, as Python has it. > > https://docs.python.org/3/reference/expressions.html#comparisons > > The problem, as explained in the Python reference, is that in `x < y < > z` the variables `x` and `z` are never compared ag

Re: [PHP-DEV] [RFC] Interval Comparison

On Mon, Nov 7, 2016 at 1:38 PM Fleshgrinder wrote: > Hey guys! :) The first one should definitely be an error since it makes no sense. Sense be damed ;-) . I'd attribute it to an identity of sorts (if it was to go all out with comparison chaining). Yes it makes little sense, in practice, but

Re: [PHP-DEV] [RFC] Interval Comparison

On Sun, Nov 6, 2016 at 1:59 PM David Rodrigues wrote: > I guess that the biggest problem is about the code parsing. Currently PHP > should supports what you wrote, but with another meaning. And personally I > think that this feature is not too common on programming language in > general, once tha

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

On Thu, Oct 13, 2016 at 10:54 AM Christoph M. Becker wrote: > On 07.10.2016 at 16:45, David Walker wrote: > > > On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov > wrote: > > > >> Are you aware of the WHATWG URL standard [1]? Quoting the first goal > >> state

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

On Mon, Oct 10, 2016 at 1:22 PM Larry Garfield wrote: > Be aware that a user-space definition for a URL object already exists as > part of PSR-7: > > http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface > > A core-provided mutable and incompatible object would be problematic. > > W

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

Hi Nikita, On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov wrote: > Are you aware of the WHATWG URL standard [1]? Quoting the first goal > statement: > > > Align RFC 3986 and RFC 3987 with contemporary implementations and > obsolete them in the process. (E.g., spaces, other "illegal" code points, >

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay wrote: > Could the new URL parser be exposed via a third parameter to parse_url, > which defaults to false/off in 7.2 (or whenever its added) but then > defaults to true in 8.0? I, personally, would be opposed to this. Firstly, it doesn't alert user

[PHP-DEV] Re: [RFC] Bug #72811 - Replacing parse_url()

On Thu, Oct 6, 2016 at 11:19 AM Christoph M. Becker wrote: So, I basically see two options: * wait until PHP 8 (whenever that'll be released) and switch the implementation of parse_url() then – what might delay the adoption of PHP 8 * add a new function in PHP 7.2 (maybe called pars

[PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

Hi all, A couple weeks back I took a look at 72811[1]. The bug being that parse_url() didn't accept IPv6 addresses without a scheme, like it did for IPv4 addresses. I attempted to patch the specific bug within the scope of how parse_url() was processing URI's. After opening a PR for the resouti

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, Sep 2, 2016 at 1:33 PM Davey Shafik wrote: > Hi internals, > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their place. > > https://wiki.php.net/rfc/deprecate-pear-include-comp

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

On Fri, Sep 2, 2016 at 9:28 AM Christoph M. Becker wrote: > On 02.09.2016 at 16:57, David Walker wrote: > > > Poking around, I'm must not be understanding how TICK opcodes would > > negatively impact the lookahead. It may be my newness, but the way I'm &g

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

te: > Looking forward won't always work out of the box. > > Take into account possible TICK opcodes, BEGIN/END silence, debugging > opcodes. > > It's probably easier to throw exception, instead of recovery, but this is > a BC break, and might be done only in 8.0.

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

On Thu, Sep 1, 2016 at 1:03 AM Dmitry Stogov wrote: > Hi David, > > I would propose to cancel voting and restart it when the good > implementation is found. > > Otherwise, people may rise their hands for something that can't be > implemented in good enough way. > > Thanks. Dmitry. > Hi Dmitry (e

[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. > >

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 >> resolv

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 > ha

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

esday, August 31, 2016 10:10:23 AM > > To: Dmitry Stogov > > Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker > > Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container > read-adccess > > > > > > Hi Dmitry, > > >

Re: [PHP-DEV] Write down a deprecation policy

On Wed, Aug 24, 2016 at 3:46 PM Stanislav Malyshev wrote: > Hi! > > > * Explicit remaining time to live of a deprecated feature (ie. in > > which future version of php this deprecated functionality will be > > dropped) > > I don't think we should be in a rush to drop deprecated things. Java, >

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

On Wed, Aug 24, 2016 at 9:48 AM Bishop Bettini wrote: > Also, it may be beneficial to elaborate on the scenarios where >> socket_addrinfo is easier to use than socket_* and friends (getservbyname >> for example) and the costs of that ease (eg, behind the scenes DNS queries). > > Most of the get*b

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

On Wed, Aug 24, 2016 at 9:58 AM Derick Rethans wrote: > On Wed, 24 Aug 2016, David Walker wrote: > > > 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, > > examinin

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

On Wed, Aug 24, 2016 at 9:36 AM Bishop Bettini wrote: > On Wed, Aug 24, 2016 at 10:58 AM, David Walker > wrote: > >> I'd like to extend the vote through Sunday evening in the event anyone had >> reservations based on potential performance impact. The RFC is currentl

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

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 [1] - https://wiki.php.net/rfc/socket_getaddrinfo

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

6 at 12:50 PM Pascal MARTIN, AFUP < mail...@pascal-martin.fr> wrote: > Le 16/08/2016 à 17:55, David Walker a écrit : > > I'd like to go ahead and open up the RFC to voting to the scope > > that it is written. > > Hi, > > At AFUP, we would be +1 on this RFC. > >

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

Will up the ante: I wasn't sure the RFC page on voting didn't really define this, I have no probs with 2/3. On Tue, Aug 16, 2016 at 11:13 AM Levi Morrison wrote: > On Tue, Aug 16, 2016 at 11:09 AM, Dan Ackroyd > wrote: > >> >> > On 16 Aug 2016, at 16:55, David

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

Hi all, I raised this concept a couple weeks ago to a couple +1's. Discussion was held mostly upon the PR [1], and I went through and documented within the RFC [2]. I'd like to go ahead and open up the RFC to voting to the scope that it is written. -- Dave [1] https://github.com/php/php-src/pu

Re: [PHP-DEV][RFC] Fixing #72733 : Implement getaddrinfo

On Thu, Aug 11, 2016 at 6:50 PM Bishop Bettini wrote: > I feel the weight of new functions, but really getaddrinfo is meant to > both simplify and unify how sockets are dealt with in the modern era. > socket_getaddrinfo converts the returned linked list into an array of, > essentially, socket con

[PHP-DEV] Fixing #72733 : Implement getaddrinfo

Hi all, I'm looking to resolve this bug, and thought about 2 means in which to implement the request of exposing C's getaddrinfo() and the addrinfo structure. There's not really an equivalent means to accomplish this in userland without trial&error. So I'm not sure the communities best-practices

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

ocations where this warning might be adversely impacting some of the tests? I know Travis will run tests when I create a PR, but I don't know if it is ensuring all tests are fully run either. Thanks -- Dave On Tue, Aug 2, 2016 at 12:33 PM David Walker wrote: > Dan, > > You're

Re: [PHP-DEV] Tracing exit()

On Thu, Aug 4, 2016 at 12:11 PM Bishop Bettini wrote: > Hi! > > exit (and its doppelganger die) is a hard stop to the engine and there is > little telemetry provided about the circumstances (file, line, message, and > code). In source I control, exit is no big deal: I don't use exit! But in > lib

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

Dan, You're right on both accounts; also, as I just notices it could easily have other BC-breaks (although expecting errors in a certain format is odd) through calls like error_get_last(), which would regardless of INI settings include this NOTICE. I will update the RFC with these changes. -- Da

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

4 Dan Ackroyd wrote: > Hi David, > > On 31 July 2016 at 20:31, David Walker wrote: > > So I want to solicit for more discussion given previous talks. My > > first-attempt RFC for this is at: > > https://wiki.php.net/rfc/notice-for-non-valid-array-container > > &g

[PHP-DEV] [RFC] E_NOTICE for invalid array container

Hi All, I'm attempting to get involved and hack away at some internals; I figured the best method to do this would be to pick up a bug and do my best at it. So I grabbed #37676. The issue asks to implement an E_(NOTICE|WARNING) when attempting to access scalar values as arrays. cmb alerted me to

[PHP-DEV] Request for rfc karma

Hi All, I'm desiring to propose my second RFC (thanks bishop for the intro) regarding PR2031 . Seems there has been a couple PR's attempting to raise a notice when accessing non-array-like containers; and I'd like to propose something to attempt to resolv

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

On Thu, Jun 23, 2016 at 1:49 PM David Walker wrote: > On Thu, Jun 23, 2016 at 12:26 PM Dmitry Stogov wrote: > >> BTW: I'm not sure what pcntl_sigaction() could return as the "oldact" >> argument..., so may be the original proposal is good enough. >>

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

sday, June 23, 2016 9:02:55 PM > *To:* PHP internals; bis...@php.net; Joe Watkins; da...@php.net > *Cc:* David Walker > *Subject:* Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler > (was Re: [PHP-DEV] pcntl_signal & sa_siginfo) > > Hi, > > > To keep maximum

[PHP-DEV] pcntl_signal & sa_siginfo

Hi All, Long-time lurker, first time questioner here. I'm currently working on a project wherein I end up forking off many subprocesses, but am trying to keep tabs on the progress of individual forks by having the children send a signal back up to their parent every so often. pcntl_socket, allow