PHP 7.0 RC1 was just tagged.
Shouldn't this be a relatively high priority to fix/decide so we don't end
up with behavior that can't be fixed until PHP 8.0?
On Sat, Aug 1, 2015 at 6:16 PM Scott Arciszewski sc...@paragonie.com
wrote:
On Sat, Aug 1, 2015 at 6:37 AM, Nikita Popov
Hi Niklas,
On Sat, Aug 1, 2015 at 5:50 PM, Niklas Keller m...@kelunik.com wrote:
You always assume the developer just wants to fallback to something
different. You can't
detect the environment btw. because it could just fail because of too many
open file descriptors.
This is not my
On Sat, Aug 1, 2015 at 6:37 AM, Nikita Popov nikita@gmail.com wrote:
tl;dr: This should definitely throw, but I'm as yet unclear as to *what* it
should throw. My gut says zpp should throw Error, length/min/max errors
should throw Error and the randomness-not-available condition should throw
functions throwing exceptions in 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
2015-08-01 1:43 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net:
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
On Sat, Aug 1, 2015 at 12:34 AM, 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 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
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 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 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 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 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 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
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 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 vote.
I just don't know where to put it in the wiki, because it's not a RFC.
Regards, Niklas
On Mon, Jul 27, 2015 at 2:03 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Rowan,
This is certainly some people's concern, but Anatol has raised a subtly
different consistency-related point, which is this:
Since we have no policy for what kinds of Throwable should be emitted in
what
2015-07-30 19:12 GMT+02:00 Scott Arciszewski sc...@paragonie.com:
On Mon, Jul 27, 2015 at 2:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Rowan,
This is certainly some people's concern, but Anatol has raised a subtly
different consistency-related point, which is this:
Since we
Scott Arciszewski wrote on 27/07/2015 07:57:
My only concern is that, we have a fixed timetable for the 7.0.0
release. It's certainly a good idea to develop a cogent strategy
before moving forward, but I worry that bikeshedding will get involved
and we won't make the deadline.
I propose that,
On Mon, Jul 27, 2015 at 10:27 AM, Rowan Collins rowan.coll...@gmail.com wrote:
Scott Arciszewski wrote on 27/07/2015 07:57:
My only concern is that, we have a fixed timetable for the 7.0.0
release. It's certainly a good idea to develop a cogent strategy
before moving forward, but I worry that
Scott Arciszewski wrote on 27/07/2015 18:35:
I understand that some of the Internals contributors are allergic to
special cases. There's some validity to wanting the language to be
predictable and consistent across the board, because that might be a
UX concern in and of itself. (What do you mean
On Mon, Jul 27, 2015 at 1:04 PM, Rowan Collins rowan.coll...@gmail.com wrote:
Scott Arciszewski wrote on 27/07/2015 15:45:
The problem with fatal errors is that This function can fail
irrecoverably outside of your control isn't going to encourage
adoption.
Well... rats! ;)
It seems
Rowan,
This is certainly some people's concern, but Anatol has raised a subtly
different consistency-related point, which is this:
Since we have no policy for what kinds of Throwable should be emitted in
what circumstance, throwing anything in this function sets a precedent which
will have
Scott Arciszewski wrote on 27/07/2015 15:45:
The problem with fatal errors is that This function can fail
irrecoverably outside of your control isn't going to encourage
adoption.
Well... rats! ;)
It seems whatever we do here is going to carry some kind of risk /
downside. :(
--
PHP
...@gmail.com; Stanislav Malyshev
smalys...@gmail.com; sc...@paragonie.com; rowan.coll...@gmail.com;
pierre@gmail.com; Dean Eigenmann dean.eigenm...@icloud.com;
Yasuo Ohgaki yohg...@ohgaki.net; PHP Internals internals@lists.php.net
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
smalys...@gmail.com; sc...@paragonie.com; rowan.coll...@gmail.com;
pierre@gmail.com; Dean Eigenmann dean.eigenm...@icloud.com;
Yasuo Ohgaki yohg...@ohgaki.net; PHP Internals internals@lists.php.net
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
I must have overlooked
kelerest...@gmail.com; Stanislav Malyshev smalys...@gmail.com;
rowan.coll...@gmail.com; Pierre Joye pierre@gmail.com; Dean
Eigenmann dean.eigenm...@icloud.com; Yasuo Ohgaki
yohg...@ohgaki.net; PHP Internals internals@lists.php.net
Subject: Re: [PHP-DEV] Core functions throwing exceptions
On 07/26/2015 01:36 PM, Jakub Kubíček wrote:
Hi Larry!
2015-07-26 1:29 GMT+02:00 Larry Garfield la...@garfieldtech.com:
Another point here is that 0 is a perfectly legitimate random number in many
cases, so callers would need to do a === check, not just a boolean check.
What boolean check are
Hi Larry!
2015-07-26 1:29 GMT+02:00 Larry Garfield la...@garfieldtech.com:
Another point here is that 0 is a perfectly legitimate random number in many
cases, so callers would need to do a === check, not just a boolean check.
What boolean check are you talkin' about? I've never seen a code
Hi,
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Sunday, July 26, 2015 9:38 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
On 07/26/2015 01:36 PM, Jakub Kubíček wrote:
Hi Larry!
2015-07-26 1
I must have overlooked a detail here.
According to https://github.com/tpunt/PHP7-Reference#throwable-interface
there are Throwables called Error, as a separate designation from an
exception. I didn't see this in the engine exceptions RFC, so I was
unaware that was even a thing.
In this
+1 for Error
On Jul 26, 2015 11:32 PM, Aaron Piotrowski aa...@icicle.io wrote:
I must have overlooked a detail here.
According to https://github.com/tpunt/PHP7-Reference#throwable-interface
there are Throwables called Error, as a separate designation from an
exception. I didn't see
On 07/24/2015 06:58 PM, Stanislav Malyshev wrote:
Hi!
On the surface, this sounds like a good thing. Although, I question that
if a user is not checking $result === false, then will they end up just
wrapping this in an empty try/catch so their code does not fail? There
is a mechanism to detect
On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski aa...@icicle.io wrote:
On Jul 14, 2015, at 4: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
Hi!
Given that the *engine itself* now throws exceptions, and we have
bundled extensions which throw exceptions, the blanket ban on exceptions
in core functions seems increasingly out-dated. This particular
I agree. I think once we agreed we want to convert from fatals to
exceptions, we need
Hi!
On the surface, this sounds like a good thing. Although, I question that
if a user is not checking $result === false, then will they end up just
wrapping this in an empty try/catch so their code does not fail? There
is a mechanism to detect the error now.
True, but not checking for false
Hi!
1. E_WARNING - fail open, possibly cause security problems for the user
2. E_ERROR - fail closed, but make graceful handling a pain in the neck
Can't you just catch Error just as you would catch an Exception? Of
course, it's less clean than specialized exception but I don't see why
it's
On Jul 14, 2015, at 4: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
Brian Moon wrote on 16/07/2015 17:19:
On the surface, this sounds like a good thing. Although, I question
that if a user is not checking $result === false, then will they end
up just wrapping this in an empty try/catch so their code does not
fail? There is a mechanism to detect the error now.
On 7/14/15 16:04 , 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_*() functions will issue a
Hi Sammy,
On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers m...@sammyk.me wrote:
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_*() functions
Sammy Kaye Powers wrote on 14/07/2015 22:04:
Since the core functions in PHP don't throw Exceptions, there is debate on
whether or not this change should be implemented. Some say the CSPRNG's
should get a special pass since they will be relied on for cryptography. If
we can't throw Exceptions,
On Wed, Jul 15, 2015 at 6:57 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Scott,
On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski sc...@paragonie.com
wrote:
On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Sammy,
On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye
Yasuo Ohgaki wrote on 15/07/2015 12:20:
Engine exception is a little different. The main motivation for engine
exception is
to give a chance to users for graceful program termination. Functions
can achieve
the objective by E_RECOVERABLE_ERROR mostly.
This is simply incorrect, as demonstrated
On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Sammy,
On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers m...@sammyk.me wrote:
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)
Hi Scott,
On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski sc...@paragonie.com
wrote:
On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Sammy,
On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers m...@sammyk.me wrote:
There are two open PR's for PHP7 to modify
Hi Rowan,
On Wed, Jul 15, 2015 at 7:57 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Sammy Kaye Powers wrote on 14/07/2015 22:04:
Since the core functions in PHP don't throw Exceptions, there is debate on
whether or not this change should be implemented. Some say the CSPRNG's
should get
try {
random_*();
} catch (SomeException $e) {
// Something
}
... is far cleaner than telling developers to override the error
handler for one specific function.
That said, I won't oppose E_RECOVERABLE_ERROR or E_ERROR if that's
what the rest of the Internals team settles on. Just don't
On Thu, Jul 16, 2015 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I understand many of us dislike INI switch nor runtime switch that changes
behavior. However, it's impossible to move to exception at once because we
have no control for users' code including 3rd party modules.
Well, ini
Hi Rowan,
On Wed, Jul 15, 2015 at 9:00 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
If we are going to adopt exception for functions, it would be better to
have
switch that convert all errors to exceptions.
Strongly disagree. A runtime switch would be a horrible consistency
nightmare
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_*() functions will issue a warning and return false if
a good source of
Would a PHP Error not work in this case? Or would the error then be interpreted
as the result?
On 14 Jul 2015, at 23:04, 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:
On Tue, Jul 14, 2015 at 5:10 PM, Dean Eigenmann
dean.eigenm...@icloud.com wrote:
Would a PHP Error not work in this case? Or would the error then be
interpreted as the result?
On 14 Jul 2015, at 23:04, Sammy Kaye Powers m...@sammyk.me wrote:
Hello lovely PHP nerds,
There are two open
56 matches
Mail list logo
