Hi!
>> I've also used it because it can adequately show the differences in how each
>> of the following options work:
>>
>> 1. Do covariant return types; check them at definition time
>> 2. Do covariant return types; check them at runtime
>> 3. Do invariant return types; check them at defin
Hi!
>> class FooFactory {
>> function create(Foo $foo): Foo { return $foo; }
>> }
>>
>> class GooFactory extends FooFactory {
>> function create(Goo $goo): Goo { return $goo; }
>> }
> OK HHVM allows it - we also allow it but trigger an E_STRICT error
> @see http://3v4l.org/UhtOb
This is b
Hi!
> I worked on an implementation of a somehow controversial concept that
> exists in hack and C#: abstract final classes.
>
> https://wiki.php.net/rfc/abstract_final_class
In the RFC, I think one phrase needs clarification:
Currently, PHP developers' only resource is to create a final class
Except for the H1 on the RFC (needs to be updated), I can really see a lot
of cases where I needed this: badly.
On Nov 27, 2014 4:48 AM, "guilhermebla...@gmail.com" <
guilhermebla...@gmail.com> wrote:
> Hi,
>
> I worked on an implementation of a somehow controversial concept that
> exists in hack
Hi,
I worked on an implementation of a somehow controversial concept that
exists in hack and C#: abstract final classes.
https://wiki.php.net/rfc/abstract_final_class
My motivation is to further expand class support to add modifiers (PPP -
public, protected, private). I added this change to init
Hi!
> While playing around with Andrea's unicode literals syntax proposal, I
> was reminded of just how little of ICU is exposed. I've put up a
> short proposal for adding IntlChar exporting these APIs as static
> methods (with a matching non-oop interface).
>
> https://wiki.php.net/rfc/intl.cha
Hi!
> I don't know if it would make a difference here, but I wonder if it
> would be sensible to add an "abstain" option in votes? That way,
> someone who has considered an RFC but not formed a strong opinion
> either way could register that fact. This could even be paired with
You could register
On Nov 26, 2014, at 17:24, Andrea Faulds wrote:
>> On 26 Nov 2014, at 23:00, Rowan Collins wrote:
>>> So far only 15 people have voted, that’s very low for this kind of RFC.
>>>
>>> I’m tempted to extend voting for another week. It’s not likely to
>>> change the outcome, but it would hopefully m
> On 26 Nov 2014, at 23:00, Rowan Collins wrote:
>
>> So far only 15 people have voted, that’s very low for this kind of RFC.
>>
>> I’m tempted to extend voting for another week. It’s not likely to
>> change the outcome, but it would hopefully mean more people vote.
>
> I don't know if it woul
On 26 November 2014 20:42:26 GMT, Andrea Faulds wrote:
>
>> On 19 Nov 2014, at 20:39, Andrea Faulds wrote:
>>
>> I am putting the Safe Casting Functions RFC to a vote.
>>
>> https://wiki.php.net/rfc/safe_cast#vote
>>
>> Voting starts today (2014-11-19) and ends in 10 days’ time
>(2014-11-29).
On 26 November 2014 10:21:12 GMT, Lazare Inepologlou wrote:
>http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Covariant_method_return_type
Can I just recommend that everyone interested in this discussion read that
whole article (at least until it gets into the guts o
Forgot to reply all, it seems.
-- Forwarded message --
From: Scott Arciszewski
Date: Wed, Nov 26, 2014 at 11:59 AM
Subject: Re: [PHP-DEV] Fwd: [php-src] Constant-Time bin2hex()
implementation (#909)
To: Ferenc Kovacs
On Wed, Nov 26, 2014 at 11:49 AM, Ferenc Kovacs wrote:
>
>>
I'm of the opinion, this:
On 26 November 2014 at 19:45, Anthony Ferrara wrote:
>
> The two mcrypt functions, IMHO **MUST** be made timing safe, no matter
> what, since they **always** deal with sensitive information.
>
Extended to any crypto functions too.
But for everything else, this:
On 26
That is why I updated the PR and made it add a function (ts_bin2hex())
instead of replacing the existing behavior.
I could have sworn I already sent this to the list.
On Wed, Nov 26, 2014 at 3:45 PM, Korvin Szanto
wrote:
> I don't like the idea of any mandatory slow down, trivial or not. This
>
I don't like the idea of any mandatory slow down, trivial or not. This
should be opt in.
On Wed, Nov 26, 2014, 12:28 PM Rasmus Lerdorf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/26/2014 11:45 AM, Anthony Ferrara wrote:
> >> That seems like a lot of functions to artificial
> On 19 Nov 2014, at 20:39, Andrea Faulds wrote:
>
> I am putting the Safe Casting Functions RFC to a vote.
>
> https://wiki.php.net/rfc/safe_cast#vote
>
> Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29).
So far only 15 people have voted, that’s very low for this kind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/2014 11:45 AM, Anthony Ferrara wrote:
>> That seems like a lot of functions to artificially slow down.
>
> Well, in most cases it shouldn't slow it down by a non-trivial
> margin.
If that can be shown definitively, then I would have fewer ob
> That seems like a lot of functions to artificially slow down.
Well, in most cases it shouldn't slow it down by a non-trivial margin.
It's not like comparison which removes the ability to short circuit,
where it can be extremely significantly longer.
When doing things like encoding or decoding,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/2014 07:29 AM, Scott Arciszewski wrote:
> http://events.ccc.de/congress/2012/Fahrplan/attachments/2235_29c3-schinzel.pdf
>
> No, a random delay is not sufficient.
Sure, I mentioned that if the scenario allows for lots of observations
then it
On 26 November 2014 at 08:49, Ferenc Kovacs wrote:
>> That's a rather extreme reaction to trying to patch string operations that
>> real-world frameworks use to handle crypto secrets, don't you think?
>>
> and there are at least that much, but probably lot more usages in the
> wild(see https://git
Thank you, Matt.
It's not easily repro-able. I'm trying to get an isolated repro.
I'll add to the existing bug 68439.
Thx!
--E.
From: Matt Ficken
Sent: Tuesday, November 25, 2014 10:16 AM
To: Eric Stenson
Cc: internals@lists.php.net
Subject: Re: [PHP
>
>
> That's a rather extreme reaction to trying to patch string operations that
> real-world frameworks use to handle crypto secrets, don't you think?
>
>
and there are at least that much, but probably lot more usages in the
wild(see https://github.com/search?l=php&q=bin2hex&type=Code&utf8=%E2%9C%
On Wed, November 26, 2014 14:38, Rowan Collins wrote:
> Anatol Belski wrote on 26/11/2014 11:34:
>
>> While it might look short cut and too
>> late for 5.5, there's indeed no scenario imaginable where such graphical
>> elements could be used even as a feature. Neither on console nor as a
>> server
On 26/11/14 16:29, Scott Arciszewski wrote:
> That's a rather extreme reaction to trying to patch string operations that
> real-world frameworks use to handle crypto secrets, don't you think?
Hmm, no.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
http://events.ccc.de/congress/2012/Fahrplan/attachments/2235_29c3-schinzel.pdf
No, a random delay is not sufficient.
Or, write yourself an extension and mirror the implementations of all
these functions. pecl/ts_string or something like that and provide
ts_bin2hex() and/or have the extension over
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2014 07:37 AM, Scott Arciszewski wrote:
> I would like to, at the minimum, suggest making the following
> functions run in constant time:
>
> * bin2hex() * hex2bin() * base64_encode() * base64_decode() *
> mcrypt_encrypt() -- requires delving
Anatol Belski wrote on 26/11/2014 11:34:
While it might look short cut and too
late for 5.5, there's indeed no scenario imaginable where such graphical
elements could be used even as a feature. Neither on console nor as a
server module or CGI.
Deciding what releases something lands in is not ju
Hi,
while investigating on https://bugs.php.net/bug.php?id=68297 it turned
out, the MessageBox'es we have on several places lead to issues. This
particular ticket describes firstly an insufficient error message, but
secondly - it goes into a popup which is then automatically logged to the
event lo
2014-11-25 23:42 GMT+01:00 Nikita Popov :
> On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
> >
> > Am 25.11.2014 um 22:43 schrieb Levi Morrison:
> >
> > On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz
> wrote:
> >>
> >>> I think it's required to do the type check on runtime (Option 2
Good morning internals,
after several weeks, I'm opening voting process for the RFC
https://wiki.php.net/rfc/aliases_by_reflection.
Thank you, Milo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Nov 25, 2014 at 11:42 PM, Nikita Popov wrote:
> On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
>>
>> Am 25.11.2014 um 22:43 schrieb Levi Morrison:
>>
>> On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz wrote:
>>>
I think it's required to do the type check on runtime (Opti
31 matches
Mail list logo
