Hi Sara,
On Sat, Jan 4, 2014 at 4:07 PM, Sara Golemon wrote:
> On Tue, Dec 31, 2013 at 1:52 PM, Yasuo Ohgaki wrote:
>> On Tue, Dec 31, 2013 at 10:53 AM, Sara Golemon wrote:
>>>
>>> On float support in GMP extension: Big +1, and I'd be happy to implement
>>> it.
>>
>> I appreciate if you impleme
> Am 23.09.2016 um 03:16 schrieb Stanislav Malyshev :
>
> Hi!
>
>> The patch is not only targeting JSON. He just used JSON as an example.
>>
>> Every function generating arrays with keys based on user-defined input
>> needs to be updated.
>
> That looks like a very good way to make a lot of mis
Hi internals!
I'd like to propose the ability of specifying declare directives like
"strict_types" at the namespace level.
The broader context of this proposal is to provide a simple and usable
mechanism that will allow developers to opt-in to stricter language
semantics on a per-library (or more
Results for project PHP master, build date 2016-09-23 06:24:49+03:00
commit: a137a1e
previous commit:923d695
revision date: 2016-09-23 03:29:56+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Am 19.09.2016 um 15:04 schrieb Vesa Kaihlavirta :
>
> $two = "2";
> if ($two > 1) {
>echo "This sorta works without strict_comparisons=1" . PHP_EOL;
> }
>
> ...would throw a TypeError exception after this change.
This sounds like a bad idea to me: Changing the language semantics of some
I find the idea of making ‘==‘ which has always been a loose comparison, have a
new optional way to be ‘more strict’ than ‘===‘ to be quite odd.
I would however love a way to have strict comparisons in a switch statement.
Cheers
Stephen
> On 23 Sep 2016, at 20:51, Christian Schneider wrote
On 23/09/2016 16:59, Stephen Reay wrote:
I would however love a way to have strict comparisons in a switch statement.
I've been pondering an idea for ages of a generalised syntax for switch
to specify an operator to use, so you'd do something like this:
switch ( $foo ) use ( === ) {
case
Hi!
> We could patch zend_hash.c in two ways: SipHash (slw) or only fatals
> (very bad for e.g. servers written in PHP. When they have to decode some
Why very bad?
> JSON, it's trivial for an attacker to crash them very easily). As that's
Fatal error is not crash. It's a normal ending of th
Hi,
On Fri, Sep 23, 2016 at 8:16 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > We could patch zend_hash.c in two ways: SipHash (slw) or only fatals
> > (very bad for e.g. servers written in PHP. When they have to decode some
>
> Why very bad?
>
> > JSON, it's trivial for an attacker to crash the
Hi!
> The broader context of this proposal is to provide a simple and usable
> mechanism that will allow developers to opt-in to stricter language
> semantics on a per-library (or more specifically, per-namespace) basis,
> thus alleviating backwards compatibility and library interoperability
> con
Hi!
> That's exactly what we don't want - let the attacker to end our request.
Why not? What else you can do with this request that has clearly bad and
maliciously constructed data?
> All other things like string overflows and memory limits are under our
> control (e.g. we can set limit on the s
Hi!
> keep in mind those 20 bits that are different in every file!". But after
> delocalizing it, all hope is lost - you never know what the code in the
> file actually means - because somebody could write code in completely
> different file, maybe even JSON composer configuration or some other
>
Hi
On Fri, Sep 23, 2016 at 8:47 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > That's exactly what we don't want - let the attacker to end our request.
>
> Why not? What else you can do with this request that has clearly bad and
> maliciously constructed data?
>
>
I think there is a confusion about t
On Fri, Sep 23, 2016 at 9:45 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > The broader context of this proposal is to provide a simple and usable
> > mechanism that will allow developers to opt-in to stricter language
> > semantics on a per-library (or more specifically, per-namespace) basis,
> > thu
>From the RFC:
> it might be beneficial to add a supports_declare() function, which allows you
> to determine whether a certain declare directive is supported, without
> resorting to a PHP version check
Even if we don't have any directives that need to be checked yet, I
think that would be a go
On Friday, September 23, 2016, Nikita Popov wrote:
> Hi internals!
>
> I'd like to propose the ability of specifying declare directives like
> "strict_types" at the namespace level.
>
> The broader context of this proposal is to provide a simple and usable
> mechanism that will allow developers t
On 23 September 2016 at 20:45, Stanislav Malyshev wrote:
> Imagine how
> fun it is if somebody's action in different code module wouldn't just
> mess up some data - it would actually break your code by changing
> language semantics for your code!
If you are concerned about libraries modifying ho
On Fri, Sep 23, 2016 at 11:58 PM, Dan Ackroyd
wrote:
> On 23 September 2016 at 20:45, Stanislav Malyshev
> wrote:
>
> > Imagine how
> > fun it is if somebody's action in different code module wouldn't just
> > mess up some data - it would actually break your code by changing
> > language semanti
On 23 September 2016 at 17:40, Rowan Collins wrote:
>
> I've been pondering an idea for ages of a generalised syntax for switch to
> specify an operator to use, so you'd do something like this:
That's technically possible already:
function foobar($foo)
{
switch (true) {
case $foo ===
Hi!
> If you are concerned about libraries modifying how code is run, the
> same theoretical problem exists with libraries that register
> autoloaders - 'omg they can totally change what code is even going to
> be run, let alone the precise semantic behaviour'.
Autoloaders do not change language
On 9/22/16 3:46 AM, Rowan Collins wrote:
I think I'm right in saying that the power of the attack comes in the fact that
the total time doesn't scale linearly but exponentially.
quadratic is what i read in the previous thread, iirc. even so, it's
still a useful gain.
That doesn't exactly
Hi!
> I think there is a confusion about the "servers written in PHP". Those
> applications serves more requests in a single (main) PHP request using
> the even loop. Good examples of that are Aerys or ReactPHP. So we don't
> want to kill that main request if one of the handled requests is
> malic
2016-09-24 0:21 GMT+02:00 Stanislav Malyshev :
> Hi!
>
> > I think there is a confusion about the "servers written in PHP". Those
> > applications serves more requests in a single (main) PHP request using
> > the even loop. Good examples of that are Aerys or ReactPHP. So we don't
> > want to kill
23 matches
Mail list logo
