Re: [PHP-DEV] Re: Serializing exceptions

Hi! week or two and I serialize exceptions (excluding stack trace arguments) to send them back to the calling process to aid in debugging process failures. But then you don't need to serialize Exception. You need to send the text representation of Exception, for humans to look at, not the live

[PHP-DEV] Re: Throwable::addSuppressed()

On 07/31/2015 08:25 PM, Markus Malkusch wrote: Stephen Coakley: Interesting thought, but how is this different than including a previous throwable and throwing a new, more descriptive exception? } catch (Exception $e1) { try { $resource->close(); } catch (ResourceExceptio

[PHP-DEV] Re: Throwable::addSuppressed()

Stephen Coakley: > Interesting thought, but how is this different than including a previous > throwable and throwing a new, more descriptive exception? > > } catch (Exception $e1) { > try { > $resource->close(); > } catch (ResourceException $e2) { > // Pass in $e2 as t

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

Ferenc, On Jul 31, 2015 6:34 PM, "Ferenc Kovacs" wrote: > > > > On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers wrote: >> >> Hello lovely PHP nerds, >> >> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: >> >> https://github.com/php/php-src/pull/1397 (main discussion)

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

On Fri, Jul 31, 2015 at 8:23 PM, Ferenc Kovacs wrote: > > > On Sat, Aug 1, 2015 at 2:00 AM, Scott Arciszewski > wrote: >> >> On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs wrote: >> > >> > On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers >> > wrote: >> > >> > > Hello lovely PHP nerds, >> > >

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

On Sat, Aug 1, 2015 at 2:00 AM, Scott Arciszewski wrote: > On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs wrote: > > > > On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers > wrote: > > > > > Hello lovely PHP nerds, > > > > > > There are two open PR's for PHP7 to modify the behavior of the > CS

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

On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs wrote: > > On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers wrote: > > > Hello lovely PHP nerds, > > > > There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: > > > > https://github.com/php/php-src/pull/1397 (main discussion) >

Re: [PHP-DEV] Re: Serializing exceptions

On 1 August 2015 00:36:58 BST, Stanislav Malyshev wrote: >Hi! > >> As I have pointed out several times, it is only the 'args' section of >> the backtrace that ever contains unserializable items. The solution > >previous could too. In fact, right now, since you can unserialize >exceptions, previous

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

Hi Niklas, On Sat, Aug 1, 2015 at 8:27 AM, Yasuo Ohgaki 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 to assume that th

Re: [PHP-DEV] Re: Serializing exceptions

On Sat, Aug 1, 2015 at 1:10 AM, Stanislav Malyshev wrote: > Hi! > > > this is where my point about we allow serializing resources just fine > > was aimed at. > > It's not "just fine". It's "it was there before we got smarter so now we > can't change it without breaking too many things". But I thi

Re: [PHP-DEV] Re: Serializing exceptions

Hi! > As I have pointed out several times, it is only the 'args' section of > the backtrace that ever contains unserializable items. The solution previous could too. In fact, right now, since you can unserialize exceptions, previous can contain literally anything and so can any other members. Als

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

Hi Niklas, On Sat, Aug 1, 2015 at 7:20 AM, Niklas Keller wrote: > 2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki : > >> Hi Niklas, >> >> On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller wrote: >> >>> Using set_error_handler isn't handling errors gracefully. Well, it's >>> better than E_ERROR, but then l

Re: [PHP-DEV] Re: Serializing exceptions

Hi! > this is where my point about we allow serializing resources just fine > was aimed at. It's not "just fine". It's "it was there before we got smarter so now we can't change it without breaking too many things". But I think we did get smarter and no longer see silently putting whatever string

Re: [PHP-DEV] Re: Serializing exceptions

Hi! > week or two and I serialize exceptions (excluding stack trace arguments) > to send them back to the calling process to aid in debugging process > failures. But then you don't need to serialize Exception. You need to send the text representation of Exception, for humans to look at, not the l

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

On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers wrote: > Hello lovely PHP nerds, > > There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: > > https://github.com/php/php-src/pull/1397 (main discussion) > https://github.com/php/php-src/pull/1398 > > Currently the random_*()

Re: [PHP-DEV] Re: Serializing exceptions

On 31 July 2015 20:56:30 BST, Stanislav Malyshev wrote: >Hi! > >> Personally I feel the restoring them impossible argument weak, >consider >> that we allow stuff like serializing resources without even a notice. > >Not sure what you mean by that. If you try to serialize resource, you >just get an

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

2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki : > Hi Niklas, > > On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller wrote: > >> Using set_error_handler isn't handling errors gracefully. Well, it's >> better than E_ERROR, but then libraries can't handle those errors >> gracefully, because the user might ove

[PHP-DEV] Re: Throwable::addSuppressed()

Stephen Coakley: > Interesting thought, but how is this different than including a previous > throwable and throwing a new, more descriptive exception? Thank you for asking. If you would have again a look at the code fragment from the previous mail you will notice that there are two immutable exce

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

Hi Niklas, On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller wrote: > Using set_error_handler isn't handling errors gracefully. Well, it's > better than E_ERROR, but then libraries can't handle those errors > gracefully, because the user might override its error handler by setting an > own handler.

Re: [PHP-DEV] Re: Serializing exceptions

On Fri, Jul 31, 2015 at 9:56 PM, Stanislav Malyshev wrote: > Hi! > > > Personally I feel the restoring them impossible argument weak, consider > > that we allow stuff like serializing resources without even a notice. > > Not sure what you mean by that. If you try to serialize resource, you > just

RE: [PHP-DEV] Re: Serializing exceptions

Hi Stas, > -Original Message- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Tuesday, July 28, 2015 10:51 PM > To: Marco Pivetta ; Rowan Collins > > Cc: Nikita Popov ; PHP Internals List > > Subject: Re: [PHP-DEV] Re: Serializing exceptions > > Hi! > > > New BC breaks

[PHP-DEV] Re: Serializing exceptions

On 07/27/2015 02:08 AM, Stas Malyshev wrote: Hi! Looking into some issue, I've discovered that, to my surprise, Exceptions are serializable. Except that it doesn't always work of course (e.g. see http://stackoverflow.com/q/9747813/214196) because exceptions contain backtraces, and those can con

Re: [PHP-DEV] Re: Serializing exceptions

On 07/28/2015 03:46 PM, Stanislav Malyshev wrote: Hi! This sort of change would be a major BC break for 8.x or similar. How is it a major BC break? You make it sound like serializing exceptions is something no application can do without. I have yet to see a single case where it's useful (yes,

Re: [PHP-DEV] Exposing object handles to userland

On Fri, Jul 31, 2015 at 4:53 PM, Nicolas Grekas < nicolas.grekas+...@gmail.com> wrote: > > I also know people that print_r($an_object) and parse the output just to >> extract the object handle from there... Crazy isn't it ? >> > > I plead guilty for doing this, but php let me no better choice for

[PHP-DEV] Re: Exposing object handles to userland

On 07/31/2015 09:23 AM, Julien Pauli wrote: Hi people. I've been pinged many times to add a new spl_object_id() function to PHP, that would return the internal object handle of an object. Today, spl_object_hash() partially allows that, but adds many randomness to the result, which is not very c

Re: [PHP-DEV] Re: Serializing exceptions

Hi! > Personally I feel the restoring them impossible argument weak, consider > that we allow stuff like serializing resources without even a notice. Not sure what you mean by that. If you try to serialize resource, you just get an integer. Not ideal, as a remanant of the times in PHP where the a

[PHP-DEV] Re: Throwable::addSuppressed()

On 07/28/2015 04:51 PM, Markus Malkusch wrote: Hi PHP So I read that there's this Throwable interface coming. Great! How about extending it with one further method: void Throwable::addSuppressed(Throwable exception) Semantic is the same as Java's Throwable.addSuppressed()¹. Why? Well consider

Re: [PHP-DEV] Re: Serializing exceptions

On Tue, Jul 28, 2015 at 6:40 PM, Stanislav Malyshev wrote: > Hi! > > > -1 on this. If there is no technical problem with serializing the > > Exception class itself, it should be possible to serialize it. It can > > always happen that an object contains some not-serializable member, this > > is no

Re: [PHP-DEV] Exposing object handles to userland

Nicolas, On Fri, Jul 31, 2015 at 2:24 PM, Nicolas Grekas wrote: >> Anthony's argument about exposing the mem layout is crucial, though. >> > > Yes it is! > > The patch I attached un-xors only the part for the object's handle. > The memory pointer is kept xored. Just checked the patch, perfect :-

Re: [PHP-DEV] Exposing object handles to userland

> Anthony's argument about exposing the mem layout is crucial, though. > Yes it is! The patch I attached un-xors only the part for the object's handle. The memory pointer is kept xored.

RE: [PHP-DEV] Exposing object handles to userland

> -Original Message- > From: nicolas.gre...@gmail.com [mailto:nicolas.gre...@gmail.com] On Behalf > Of Nicolas Grekas > Sent: Friday, July 31, 2015 6:11 PM > To: Anatol Belski > Cc: Julien Pauli ; PHP Internals ; > Sebastian Bergmann ; Ivan Enderlin@Hoa > ; cont...@jubianchi.fr > Subject

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 Thu, Jul 30, 2015 at 8:38 AM, Craig Francis wrote: > On 30 Jul 2015, at 16:26, Ronald Chmara wrote: > > Perhaps I have missed something in this discussion > I think you have... my email from a couple of weeks ago was ignored... so > I replied to Matt's suggestion (which is similar, but differ

Re: [PHP-DEV] Exposing object handles to userland

Julien, On Fri, Jul 31, 2015 at 10:23 AM, Julien Pauli wrote: > Hi people. > > I've been pinged many times to add a new spl_object_id() function to PHP, > that would return the internal object handle of an object. > > Today, spl_object_hash() partially allows that, but adds many randomness to >

RE: [PHP-DEV] Exposing object handles to userland

Hi Nicolas, Have you checked the impact of changing the existing function? Like https://github.com/sebastianbergmann/phpunit/search?utf8=%E2%9C%93 &q=spl_object_hash https://github.com/symfony/symfony/

Re: [PHP-DEV] Exposing object handles to userland

> > Have you checked the impact of changing the existing function? > Yes I did, and this breaks absolutely nothing: the spl_object_hash output has exactly the same format (otherwise it's a bug). > > > > > http

Re: [PHP-DEV] Exposing object handles to userland

> I also know people that print_r($an_object) and parse the output just to > extract the object handle from there... Crazy isn't it ? > I plead guilty for doing this, but php let me no better choice for now ;) The attached patch removes the XOR hashing for the object handle (it's useless, the "se

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

Thanks for the feedback Joe! To be clear, this feature is not an alternative to coding SQL securely with parameterized queries. Indeed, it's entire purpose is to help developers move dangerously coded queries (i.e. ones that are not parameterized and are dynamically constructed using parameters th

RE: [PHP-DEV] Exposing object handles to userland

Hi, > -Original Message- > From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of > Julien Pauli > Sent: Friday, July 31, 2015 4:24 PM > To: PHP Internals > Subject: [PHP-DEV] Exposing object handles to userland > > Hi people. > > I've been pinged many times to add a ne

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 31 Jul 2015, at 15:00, Joe Watkins wrote: > Even the best implementation need only have a single hole in it and > everything falls apart, one extension not doing something properly, or one > mistake in the implementation ... it's not hard to imagine these things > happening, right ? Hi

RE: [PHP-DEV] Introduction and some opcache SSE related stuff

Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance increase for the new version of fast_memcpy() compared with the generic memcpy(). Same result using a full load test with http_load on a Haswell EP 18 cores. >>> >>> 1% is really big improvement. >>> I'

[PHP-DEV] Exposing object handles to userland

Hi people. I've been pinged many times to add a new spl_object_id() function to PHP, that would return the internal object handle of an object. Today, spl_object_hash() partially allows that, but adds many randomness to the result, which is not very cool to use later (why does it even add random

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 28/07/15 18:33, Matt Tait wrote: > What do you all think? There's obviously a bit more work to do; the PoC > currently only covers mysqli_query, but I thought this stage is an > interesting point to throw it open to comments before working to complete > it. So who addresses all the other databa

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

Hi Matt, I take it all back... I've been so sure of my own suggestion, I've not really given your RFC a proper read... and I think this could work. The main difference I had was the ability to support to support the escaping functions (see pg_escape_literal for PostgreSQL, or htmlentities for h

RE: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30

> -Original Message- > From: Christopher Jones [mailto:christopher.jo...@oracle.com] > Sent: Friday, July 31, 2015 1:12 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30 > > > > On 30/07/2015 11:12 pm, Niklas Keller wrote: > > 2015-07-3

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

Morning Craig, I think Pierre and I object to the concept, regardless of the intricacies of any particular implementation. Even the best implementation need only have a single hole in it and everything falls apart, one extension not doing something properly, or one mistake in the implemen

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

>> This may have been true at one point in time, but my own experience >> and the statistics collected by Dan Kaminsky of White Hat Security >> indicates that Cross-Site Scripting vulnerabilities are much more >> prevalent in 2015 than SQL Injection, especially in business >> applications. If Googl

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 30 Jul 2015, at 17:02, Joe Watkins wrote: > Even if some of those people replying haven't read or don't understand what > you are suggesting, it is not a good tactic to assume that and reply with > "read the RFC". Hi Joe, Sorry about yesterday, I have done as you have said, and I have re

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

Using set_error_handler isn't handling errors gracefully. Well, it's better than E_ERROR, but then libraries can't handle those errors gracefully, because the user might override its error handler by setting an own handler. Regards, Niklas 2015-07-31 11:46 GMT+02:00 Yasuo Ohgaki : > Hi Niklas, >

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

Hi Niklas, On Fri, Jul 31, 2015 at 5:12 PM, Niklas Keller wrote: > I think the question is more whether Exception or Error (class, not > E_RECOVERABLE_ERROR), to allow handling it gracefully. > E_WARNING is too weak for CSPRNG not available. It's fatal error. I agree fatal errors should be abl

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

2015-07-31 9:29 GMT+02:00 Yasuo Ohgaki : > Hi Scott, > > On Fri, Jul 31, 2015 at 6:33 AM, Scott Arciszewski > wrote: > >> On Jul 30, 2015 2:27 PM, "Niklas Keller" wrote: >> > I prefer Exception, too, because it's I/O related. >> > >> > @Scott: You can open votes on everything, doesn't matter, ju

[PHP-DEV] Benchmark Results for PHP Master 2015-07-31

Results for project php-src-nightly, build date 2015-07-31 05:00:00+03:00 commit: ac87657d4219111ecc52f2b6f27f5a739f0379a3 revision_date: 2015-07-31 02:44:42+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] json_decode/encode should return full precision values by default

Hi Nikita, On Thu, Jul 30, 2015 at 6:06 PM, Nikita Popov wrote: > On Thu, Jul 30, 2015 at 1:25 AM, Yasuo Ohgaki wrote: > >> Hi all, >> >> On Thu, Jul 30, 2015 at 7:44 AM, Yasuo Ohgaki wrote: >> >>> On Thu, Jul 30, 2015 at 1:13 AM, Nikita Popov >>> wrote: >>> Instead of continuing to use

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

Hi Scott, On Fri, Jul 31, 2015 at 6:33 AM, Scott Arciszewski wrote: > On Jul 30, 2015 2:27 PM, "Niklas Keller" wrote: > > I prefer Exception, too, because it's I/O related. > > > > @Scott: You can open votes on everything, doesn't matter, just create a > page with a vote. > > I just don't know