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
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
On 1 August 2015 00:36:58 BST, Stanislav Malyshev smalys...@gmail.com 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
On Sat, Aug 1, 2015 at 2:00 AM, Scott Arciszewski sc...@paragonie.com
wrote:
On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me
wrote:
Hello lovely PHP nerds,
There are two open PR's for PHP7
Ferenc,
On Jul 31, 2015 6:34 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me 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
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 the
On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me 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
On Fri, Jul 31, 2015 at 8:23 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Sat, Aug 1, 2015 at 2:00 AM, Scott Arciszewski sc...@paragonie.com
wrote:
On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me
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
On 31 Jul 2015, at 15:00, Joe Watkins pthre...@pthreads.org 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
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
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 Google has
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
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
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'll able to check this only
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 internals@lists.php.net
Subject: [PHP-DEV] Exposing object handles to userland
Hi people.
I've been pinged many
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
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 database
-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-30 14:42
Julien,
On Fri, Jul 31, 2015 at 10:23 AM, Julien Pauli jpa...@php.net 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
Hi Nicolas,
Have you checked the impact of changing the existing function? Like
https://github.com/sebastianbergmann/phpunit/search?utf8=%E2%9C%93
https://github.com/sebastianbergmann/phpunit/search?utf8=%E2%9C%93q=spl_object_hash
q=spl_object_hash
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).
https://github.com/sebastianbergmann/phpunit/search?utf8=%E2%9C%93q=spl_object_hash
On Thu, Jul 30, 2015 at 8:38 AM, Craig Francis cr...@craigfrancis.co.uk
wrote:
On 30 Jul 2015, at 16:26, Ronald Chmara rona...@gmail.com 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
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.
-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 anatol@belski.net
Cc: Julien Pauli jpa...@php.net; PHP Internals internals@lists.php.net;
Sebastian Bergmann
On Tue, Jul 28, 2015 at 6:40 PM, Stanislav Malyshev smalys...@gmail.com
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,
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
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
Nicolas,
On Fri, Jul 31, 2015 at 2:24 PM, Nicolas Grekas
nicolas.grekas+...@gmail.com 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
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 now ;)
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
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
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
Hi Stas,
-Original Message-
From: Stanislav Malyshev [mailto:smalys...@gmail.com]
Sent: Tuesday, July 28, 2015 10:51 PM
To: Marco Pivetta ocram...@gmail.com; Rowan Collins
rowan.coll...@gmail.com
Cc: Nikita Popov nikita@gmail.com; PHP Internals List
internals@lists.php.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, 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
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, it's
better than E_ERROR, but then libraries can't handle those errors
gracefully,
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
Hi Scott,
On Fri, Jul 31, 2015 at 6:33 AM, Scott Arciszewski sc...@paragonie.com
wrote:
On Jul 30, 2015 2:27 PM, Niklas Keller m...@kelunik.com 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
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
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 in
On Sat, Aug 1, 2015 at 1:10 AM, Stanislav Malyshev smalys...@gmail.com
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.
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,
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.
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 to
On Fri, Jul 31, 2015 at 9:56 PM, Stanislav Malyshev smalys...@gmail.com
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
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
On 31 July 2015 20:56:30 BST, Stanislav Malyshev smalys...@gmail.com 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
On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me 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
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
Hi Niklas,
On Fri, Jul 31, 2015 at 5:12 PM, Niklas Keller m...@kelunik.com 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
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
On 30 Jul 2015, at 17:02, Joe Watkins pthre...@pthreads.org 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
52 matches
Mail list logo
