[PHP-DEV] Enable error_handler callback parameters to be passed by reference

In userland it is sometimes necessary to extend PHP's notices/warnings with additional information (e.g. username from session, stack trace, etc.) I'm proposing to enable error_handler callback parameters to be passed by reference to be able to append additional data to error messages. Example:

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

On Tue, Jan 20, 2015 at 8:33 PM, marius adrian popa wrote: > interbase extension is maintained and at least i will rename to firebird > after php7 api conversion is over (a few blob/events tests don't pass after > the big api changes ) There are two questions, maintained or dead cow. My worries

Re: [PHP-DEV] 8.0 is not 10 years away

> Occasionally, in various discussions, waiting for the next major release is > described as "maybe another 10 years", but I think that's a very pessimistic > prediction. It's more reasonable to expect it in half that time, around > 2020, and that is what we should base our decisions on. I am fair

Re: [PHP-DEV] Fixing strange foreach behavior.

Hi Rowan, On Mon, Jan 19, 2015 at 12:05 AM, Rowan Collins wrote: > On 18 January 2015 at 01:01, Yasuo Ohgaki wrote: > >> Hi Rowan, >> >> On Sat, Jan 17, 2015 at 8:43 PM, Rowan Collins >> wrote: >> >>> My concern is, at what cost? Given how rarely used the internal pointer >>> is, >>> are we ca

Re: [PHP-DEV] Re: Help - gcc mystery in ext/imap

On 01/20/2015 02:46 PM, Stanislav Malyshev wrote: > Hi! > >> So, I guess the lesson is that we need to be careful when we migrate >> extensions to PHP 7. Passing ints instead of size_t string length params >> to zpp can cause extreme weirdness and we should go through all our >> bundled extensions

Re: [PHP-DEV] [RFC] Skipping parameters take 2

On 20 January 2015 at 20:09, Marc Bennewitz wrote: > Pros & Cons > > _Named Parameters:_ > pro: > - readability (If caller is not required to call as assoc array) > - not an option for inheritance > con: > - paramter skipping is a side product with possible edge cases > - Adds var

Re: [PHP-DEV] Re: Help - gcc mystery in ext/imap

Hi! > So, I guess the lesson is that we need to be careful when we migrate > extensions to PHP 7. Passing ints instead of size_t string length params > to zpp can cause extreme weirdness and we should go through all our > bundled extensions and make sure things that are still using "s" have > all

Re: [PHP-DEV] Re: Help - gcc mystery in ext/imap

On Tue, 2015-01-20 at 14:13 -0800, Rasmus Lerdorf wrote: > So, I guess the lesson is that we need to be careful when we migrate > extensions to PHP 7. Passing ints instead of size_t string length params > to zpp can cause extreme weirdness and we should go through all our > bundled extensions and m

RE: [PHP-DEV] [RFC] Remove PHP 4 Constructors

> De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part > > I'm happy to update the manual, but I think I'd want more of a > consensus (not necessarily a formal RFC, but at least a straw poll) > for "soft deprecation" (to reuse the term we used for mysql_* before > it started generatin

RE: [PHP-DEV] in Operator

> De : Rowan Collins [mailto:rowan.coll...@gmail.com] > > Given the ability to write foreach ( $foo as $key => $value ), I'm not > sure adding a variant syntax of for ( $key in $foo ) has that much value > for PHP. +1. Useless and ambiguous. -- PHP Internals - PHP Runtime Development Mailing L

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

On Mon, 2015-01-19 at 18:07 +0100, Anatol Belski wrote: > Hi, > > I think the research on > https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough > to be discussed. > > So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet. > But independent from that, it'd

[PHP-DEV] Re: Help - gcc mystery in ext/imap

On 01/20/2015 01:54 PM, Rasmus Lerdorf wrote: > Things I have tried. changed it from "p" to "s" and also from "p" to "S" > and using a zend_string * instead. In both cases I got the same bogus > address back from zpp. Right now I am trying to make sense of the > generated assembly differences, but

Re: [PHP-DEV] Casting a PHP type, new SAPI

Hi, On Tue, 2015-01-20 at 06:36 +0100, Kevin Ingwersen (Ingwie Phoenix) wrote: > Today I have started to concept a new SAPI which I have wanted to do > in quite a while now. To learn more, here is a README: > https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md >

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

On 20.01.2015 22:46, Nikita Popov wrote: On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz mailto:dev@mabe.berlin>> wrote: valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls: - string "MyClass::staticFunc" - string "self::staticFunc"

[PHP-DEV] Help - gcc mystery in ext/imap

In testing PHP7 beyond just the default extensions, I am noticing that ext/imap is segfaulting on almost every test. I tracked it down to this code in ext/imap/php_imap.c: /* {{{ imap_do_open */ static void php_imap_do_open(INTERNAL_FUNCTION_PARAMETERS, int persistent) { char *mailbox, *u

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz wrote: > valid for call_user_func[_array] and callable type-hint but invalid for > for direct variable calls: > - string "MyClass::staticFunc" > - string "self::staticFunc" > - string "static::staticFunc" > - string "parent::func" > - string "parent

Re: [PHP-DEV] [RFC] Skipping parameters take 2

On 20/01/2015 20:09, Marc Bennewitz wrote: Am 19.01.2015 um 19:48 schrieb Adam Harvey: On 17 January 2015 at 18:04, Andrea Faulds wrote: For consistency with list(), we could also just put nothing: foo($bar, , $baz); Which is like: list($bar, , $baz) = $arr; Thoughts? That was

[PHP-DEV] 8.0 is not 10 years away

Hi All! Occasionally, in various discussions, waiting for the next major release is described as "maybe another 10 years", but I think that's a very pessimistic prediction. It's more reasonable to expect it in half that time, around 2020, and that is what we should base our decisions on. The

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

On Tue, Jan 20, 2015 at 1:59 PM, Adam Harvey wrote: > On 20 January 2015 at 12:54, Marc Bennewitz wrote: >> valid for call_user_func[_array] and callable type-hint but invalid for for >> direct variable calls: >> - string "MyClass::staticFunc" >> - string "self::staticFunc" >> - string "static::s

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

Hey Adam, > On 20 Jan 2015, at 20:59, Adam Harvey wrote: > > On 20 January 2015 at 12:54, Marc Bennewitz wrote: >> valid for call_user_func[_array] and callable type-hint but invalid for for >> direct variable calls: >> - string "MyClass::staticFunc" >> - string "self::staticFunc" >> - string "

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

On 20 January 2015 at 12:54, Marc Bennewitz wrote: > valid for call_user_func[_array] and callable type-hint but invalid for for > direct variable calls: > - string "MyClass::staticFunc" > - string "self::staticFunc" > - string "static::staticFunc" > - string "parent::func" > - string "parent::sta

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

Hey Marc, > On 20 Jan 2015, at 20:54, Marc Bennewitz wrote: > > valid for call_user_func[_array] and callable type-hint but invalid for for > direct variable calls: > - string "MyClass::staticFunc" > - string "self::staticFunc" > - string "static::staticFunc" > - string "parent::func" > - strin

[PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls: - string "MyClass::staticFunc" - string "self::staticFunc" - string "static::staticFunc" - string "parent::func" - string "parent::staticFunc" see http://3v4l.org/1oSO3 Thoughts ? -- PHP Interna

Re: [PHP-DEV] [PATCH] Fix uninitalized variables reads. See CWE-457 for more info.

On 21/01/15 07:28, Joshua Rogers wrote: > --- > ext/mbstring/mbstring.c | 8 > ext/reflection/php_reflection.c | 1 + > main/main.c | 1 + > 3 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/ext/mbstring/mbstring.c b/ext/mbstring/mbstring.c > in

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

On 20/01/15 19:33, marius adrian popa wrote: > pdo_firebird is ok but doesn't cover the firebird api so we still need them > both And I would add to that - PDO does not allow cross database transactions which is another area interbase/firebird can utilise. It's particularly useful archiving histor

[PHP-DEV] [PATCH] Fix uninitalized variables reads. See CWE-457 for more info.

--- ext/mbstring/mbstring.c | 8 ext/reflection/php_reflection.c | 1 + main/main.c | 1 + 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/ext/mbstring/mbstring.c b/ext/mbstring/mbstring.c index 7f2209f..504a5e6 100644 --- a/ext/mbstring/mbstring

Re: [PHP-DEV] [RFC] Skipping parameters take 2

Hi! > @Stas: Any news on using default on inheritance ? Not yet, probably will look into this towards next weekend. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Skipping parameters take 2

Am 19.01.2015 um 19:48 schrieb Adam Harvey: On 17 January 2015 at 18:04, Andrea Faulds wrote: For consistency with list(), we could also just put nothing: foo($bar, , $baz); Which is like: list($bar, , $baz) = $arr; Thoughts? That was Stas's original, original proposal way back

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

Ok, in that case I'll take back some of my words. Would you please remove my name from the maintainers if it is still there? I don't expect to be able to contribute or fix anything anymore. -- Jouni Ahto On 01/20/2015 09:33 PM, marius adrian popa wrote: interbase extension is maintained and a

Re: [PHP-DEV] Static Closures and PHP 7

Am 20.01.2015 um 18:58 schrieb Levi Morrison: Internals, Last year I "fixed" the behavior of closures in a few regards, which were included in PHP 5.5.14 and 5.6 (unsure on exact version): - Static closures properly use late-static binding on `static::` calls from inside static methods.

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

Here are the issues with master (008 is rounding issue so you can ignore for the moment) FAILED TEST SUMMARY - InterBase: BLOB test [ext/interbase/tests/004.phpt] InterBase: transactions [ext/interbase/tests/005.phpt] InterBase: a

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

> > #1 and #2 may be considered to be genuine improvements by the user > community, but #3 most certainly will not. It does not matter how you > try to dress it up, forcing your end users to jump through hoops before > they can upgrade is a customer relations disaster. PHP and other scripting lan

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

interbase extension is maintained and at least i will rename to firebird after php7 api conversion is over (a few blob/events tests don't pass after the big api changes ) Dmitry Stogov added some patches but we need to fix the zend engine

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

At least one mail didn't bounce. The situation with Interbase extension, in my opinion: it's dead meat and should most probably be just removed. Nobody is currently, to my knowledge, maintaining it. Even the birth of said extension was a bit troublesome, when I had just for the fun of it writt

Re: [PHP-DEV] in Operator

Hi! > Agree, but maybe a RFC for "in" operator and a follow up RFC to allow > "in" on "for" context could be a win/win here as long as one feature > doesn't block each other? The problem is "in" is not just "for". The problem is this: when you say "$foo in $bar", is $foo a value or a key? In many

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On 20 January 2015 at 07:09, Kristopher wrote: > @everyone: Would an RFC be necessary to update the PHP manual to actually > recommend the PHP 5 constructors and recommend against using the PHP 4 > style constructors, using very explicit language? If not, should this > change be made, regardless o

Re: [PHP-DEV] [PATCH] Remove useless tests

On 21/01/15 05:32, Alexey Zakhlestin wrote: >> > On 20 Jan 2015, at 21:00, Joshua Rogers wrote: >> > >> > Respective variables are unsigned and cannot be <0. > Did you mean to use “==“ in comparisons? > > Yes. Fixed it in the pull request: https://github.com/MegaManSec/php-src/commit/eba0e0348e97

Re: [PHP-DEV] [PATCH] Remove useless tests

> On 20 Jan 2015, at 21:00, Joshua Rogers wrote: > > Respective variables are unsigned and cannot be <0. Did you mean to use “==“ in comparisons? > --- > sapi/litespeed/lsapilib.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/sapi/litespeed/lsapilib.c b/s

[PHP-DEV] [PATCH] Remove useless tests

Respective variables are unsigned and cannot be <0. --- sapi/litespeed/lsapilib.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c index 2e60701..20279d1 100644 --- a/sapi/litespeed/lsapilib.c +++ b/sapi/litespeed/

[PHP-DEV] Static Closures and PHP 7

Internals, Last year I "fixed" the behavior of closures in a few regards, which were included in PHP 5.5.14 and 5.6 (unsure on exact version): - Static closures properly use late-static binding on `static::` calls from inside static methods. - Non-static closures in static methods are automat

Re: [PHP-DEV] in Operator

Am 20.01.2015 um 16:42 schrieb Rowan Collins: > Given the ability to write foreach ( $foo as $key => $value ), I'm not > sure adding a variant syntax of for ( $key in $foo ) has that much value > for PHP. I totally agree with you here. The only real reason why Javascript has a for-in operation t

Re: [PHP-DEV] in Operator

Mike Willbanks wrote on 20/01/2015 03:30: I am very familiar with the in operator. However, the implementation would be incomplete without handling loops via the in operator. Many people when seeing an in operator also think of JavaScript. In that case the in operator iterates over properties

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston wrote: @tony: What's really interesting is that all this time you've spent arguing could have been used to update your code and make this no longer an issue for you. @everyone: Would an RFC be necessary to update the PHP manual to actually recommend

Re: [PHP-DEV] in Operator

Mike, Back to the subject,: > It is indeed different but ever so slightly, a for loop in this case cannot > handle a single argument of true and would cause a parse error. > Therefore for ("PHP" in ["PHP, "C", "Java"]) could be handled differently. > Again, my main point is that due to other

Re: [PHP-DEV] in Operator

Mike, > Also FYI - in the future please try not to top post and instead post under > where you are commenting as it makes it more difficult for > people coming later to the thread to see the scope of the conversation. Thanks for the tip! I read to "do not top post" on the guidelines but had no c

Re: [PHP-DEV] in Operator

Hello, On Tue, Jan 20, 2015 at 7:47 AM, Marcio Almada wrote: > Hi, > > Mike, the use of "in" as `for ($var in $object) {};` could be the > subject for another distinct RFC since it's doing something different > from the original proposal: > > var_dump("PHP" in ["PHP", "C", "Java"]); // true > I

Re: [PHP-DEV] Remove old PHP4 extension loading code

Hey: On Tue, Jan 20, 2015 at 9:43 PM, Julien Pauli wrote: > Hi ! > > Here is a PR removing our old PHP4 zend_module_entry structure > compatibility. > I'm about to merge it against master, if no-one objects. > > https://github.com/php/php-src/pull/988 I see no problem at all thanks > > > Julien.

Re: [PHP-DEV] in Operator

Hi, Mike, the use of "in" as `for ($var in $object) {};` could be the subject for another distinct RFC since it's doing something different from the original proposal: var_dump("PHP" in ["PHP", "C", "Java"]); // true 2015-01-20 10:41 GMT-03:00 Mike Willbanks : > Hello Pierre, Andrea and Niklas,

[PHP-DEV] Remove old PHP4 extension loading code

Hi ! Here is a PR removing our old PHP4 zend_module_entry structure compatibility. I'm about to merge it against master, if no-one objects. https://github.com/php/php-src/pull/988 Julien.P

Re: [PHP-DEV] in Operator

Hello Pierre, Andrea and Niklas, On Mon, Jan 19, 2015 at 11:35 PM, Pierre Joye wrote: > On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds wrote: > >> On 20 Jan 2015, at 03:30, Mike Willbanks wrote: > >> > >> I am very familiar with the in operator. However, the implementation > >> would be inco

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

"Rowan Collins" wrote in message news:54bd4d98.80...@gmail.com... Tony Marston wrote on 19/01/2015 16:24: "Rowan Collins" wrote in message news:54bd240a.7050...@gmail.com... Tony Marston wrote on 19/01/2015 15:01: The aim should be to eliminate customer grievances as much as possible and n

[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: Broken apps

On Tue, Jan 20, 2015 at 6:55 AM, Andrea Faulds wrote: > Hi again, > > > On 19 Jan 2015, at 10:28, Andrea Faulds wrote: > > > >> On 19 Jan 2015, at 10:24, Dmitry Stogov wrote: > >> > >> There are also a number of tests started to fail since last Friday > >> > >>> testing integer overflow (32bit)

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

Hi, On Tue, January 20, 2015 06:26, Pierre Joye wrote: > On Tue, Jan 20, 2015 at 6:08 AM, Dmitry Stogov wrote: > >> Hi Anatol, >> >> >> Despite of this, we also have few extensions not converted to PHP7 yet >> - >> https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet >> >> >> 3 of

Re: [PHP-DEV] Re: Improvements to array.c code base

Hey: On Tue, Jan 20, 2015 at 5:21 PM, Benjamin Coutu wrote: > Sorry, your right of course as not preserving keys only applies to numeric > indices. np, advise and questions on performance are always welcome :) thanks > > == Original == > From: Xinchen Hui > To: Benjamin Coutu

Re: [PHP-DEV] in Operator

2015-01-20 6:35 GMT+01:00 Pierre Joye : > On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds wrote: >> Hi Mike, >> >>> On 20 Jan 2015, at 03:30, Mike Willbanks wrote: >>> >>> I am very familiar with the in operator. However, the implementation >>> would be incomplete without handling loops via the

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

Hi Dmitry, On Tue, January 20, 2015 06:08, Dmitry Stogov wrote: > Hi Anatol, > > > Despite of this, we also have few extensions not converted to PHP7 yet - > https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet > > > 3 of them related to MSSQL, 2 to Oracle and one to Interbase. the

Re: [PHP-DEV] Re: Improvements to array.c code base

Sorry, your right of course as not preserving keys only applies to numeric indices. == Original == From: Xinchen Hui To: Benjamin Coutu Date: Tue, 20 Jan 2015 10:13:04 +0100 Subject: Re: [PHP-DEV] Re: Improvements to array.c code base Hey: On Tue, Jan 20, 2015 at 5:06 PM, Be

Re: [PHP-DEV] Re: Improvements to array.c code base

Hey: On Tue, Jan 20, 2015 at 5:06 PM, Benjamin Coutu wrote: > Hi, > > Regarding ARRAY_SLICE(..., preserve_keys=false) my whole point was that the > check for non-numeric key inputs is not necessary if preserve_keys is false. > It should basically be analogue to array_values(), but of course resp

Re: [PHP-DEV] Re: Improvements to array.c code base

Hi, Regarding ARRAY_SLICE(..., preserve_keys=false) my whole point was that the check for non-numeric key inputs is not necessary if preserve_keys is false. It should basically be analogue to array_values(), but of course respecting the offset and length boundaries. One question regarding FAST_

[PHP-DEV] Re: Improvements to array.c code base

Hey: On Tue, Jan 20, 2015 at 4:30 PM, Benjamin Coutu wrote: > Hi Dmitry, > > I was doing some code review of ext/standard/array.c and have recognized some > potential for a few performance improvements: > > === ARRAY_SLICE(..., preserve_keys=false) === > > array_slice() can always construct a p

[PHP-DEV] Improvements to array.c code base

Hi Dmitry, I was doing some code review of ext/standard/array.c and have recognized some potential for a few performance improvements: === ARRAY_SLICE(..., preserve_keys=false) === array_slice() can always construct a packed array if preserve_keys is false, restricting it to inputs with packed