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
wrote:
> On Sat, Aug 1, 2015 at 6:37 AM, Nikita Popov wrote:
> > tl;dr: This should defini
On Sat, Aug 1, 2015 at 6:37 AM, Nikita Popov 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
> Exception.
Hi
Hi Niklas,
On Sat, Aug 1, 2015 at 5:50 PM, Niklas Keller 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 assumption, but oth
On Sat, Aug 1, 2015 at 12:34 AM, 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)
>>
2015-08-01 1:43 GMT+02:00 Yasuo Ohgaki :
> 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 implemen
Hi Anthony,
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Saturday, August 1, 2015 2:34 AM
> To: Ferenc Kovacs
> Cc: Sammy Kaye Powers ; internals@lists.php.net; Nikita
> Popov
> Subject: Re: [PHP-DEV] Core functions throwi
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)
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,
>> > >
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
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)
>
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
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
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_*()
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
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.
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,
>
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
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
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
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 where to put it in the wiki, because it's not a RFC.
>
> Regards, Niklas
I'm not s
2015-07-30 19:12 GMT+02:00 Scott Arciszewski :
> On Mon, Jul 27, 2015 at 2:03 PM, Anthony Ferrara
> 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 wha
On Mon, Jul 27, 2015 at 2:03 PM, Anthony Ferrara 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 circumstance,
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
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 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 whatever we d
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 Intern
On Mon, Jul 27, 2015 at 10:27 AM, Rowan Collins 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 bikeshedding w
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, if
.@gmail.com; Pierre Joye ; Dean
> Eigenmann ; Yasuo Ohgaki
> ; PHP Internals
> Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
>
> 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 strate
onie.com; rowan.coll...@gmail.com;
>> pierre@gmail.com; Dean Eigenmann ;
>> Yasuo Ohgaki ; PHP Internals
>> Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
>>
>>
>> > I must have overlooked a detail here.
>> >
>> > According
aragonie.com; rowan.coll...@gmail.com;
> pierre@gmail.com; Dean Eigenmann ;
> Yasuo Ohgaki ; PHP Internals
> Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
>
>
> > I must have overlooked a detail here.
> >
> > According to
> > https://gi
+1 for Error
On Jul 26, 2015 11:32 PM, "Aaron Piotrowski" 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 this i
> 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.
>
> I
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íče
On 07/26/2015 01:36 PM, Jakub Kubíček wrote:
Hi Larry!
2015-07-26 1:29 GMT+02:00 Larry Garfield :
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
Hi Larry!
2015-07-26 1:29 GMT+02:00 Larry Garfield :
> 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
using e.g. strpos() lik
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
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 n
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 fa
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 n
On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski wrote:
>
>> On Jul 14, 2015, at 4: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)
>> http
> On Jul 14, 2015, at 4: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_*
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 warni
On Thu, Jul 16, 2015 at 4:58 AM, Yasuo Ohgaki 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 settiing remains
Hi Rowan,
On Wed, Jul 15, 2015 at 9:00 PM, Rowan Collins
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 for userland
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
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 e
On Wed, Jul 15, 2015 at 6:57 AM, Yasuo Ohgaki wrote:
> Hi Scott,
>
> On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski
> wrote:
>>
>> On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
>> > Hi Sammy,
>> >
>> > On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers wrote:
>> >
>> >> There are two
Hi Rowan,
On Wed, Jul 15, 2015 at 7:57 PM, Rowan Collins
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 a special pass s
Hi Scott,
On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski
wrote:
> On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
> > Hi Sammy,
> >
> > On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers wrote:
> >
> >> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:
> >>
> >>
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, th
On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
> Hi Sammy,
>
> On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers 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/p
Hi Sammy,
On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers 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 will iss
On Tue, Jul 14, 2015 at 5:10 PM, Dean Eigenmann
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 wrote:
>>
>> Hello lovely PHP nerds,
>>
>> There are two open PR's for PHP7 to modify the b
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 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
56 matches
Mail list logo
