On Thu, Oct 23, 2014 at 1:34 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Andrey Andreev [mailto:n...@devilix.net]
>> Sent: Thursday, October 23, 2014 1:15 AM
>> To: Zeev Suraski
>> Cc: Andrea Faulds; Stas Malyshev; Dmitry Stogov; PHP Internals
>> Subject: Re: [PHP-DEV] [RFC] Saf
> -Original Message-
> From: Andrey Andreev [mailto:n...@devilix.net]
> Sent: Thursday, October 23, 2014 1:15 AM
> To: Zeev Suraski
> Cc: Andrea Faulds; Stas Malyshev; Dmitry Stogov; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
> > While it doesn't explicitly say so
On 22/10/14 22:12, Zeev Suraski wrote:
> Something like:
>
> If (!int_convertible($sth)) { // open to new ideas about the name :)
> // error out
> }
> $i = (int) $sth;
And this allows each failure with it's own response, while pushing that
problem to an exception requires one builds a tree
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, October 23, 2014 12:42 AM
> To: Stas Malyshev
> Cc: Zeev Suraski; Dmitry Stogov; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
>
> > On 22 Oct 2014, at 22:31, Stas Malyshev
> wrote:
>
Hi,
On Thu, Oct 23, 2014 at 1:01 AM, Zeev Suraski wrote:
> The RFC itself makes an assertion that fundamentally contradicts the notion
> that these are 'just functions'. The RFC reads 'They also prevent any
> suggestion of strict type hinting for scalar types, because if that were to
> be added,
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, October 22, 2014 9:20 PM
> To: Stas Malyshev; Zeev Suraski
> Cc: Dmitry Stogov; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
>
> > On 22 Oct 2014, at 09:17, Stas Malyshev
> wrote:
>
Trying to think what real world example may look like. With exceptions:
try {
$i = lossless_int($sth);
} catch (SomeException $e) {
// error out / provide default / custom error handling
}
If we use FALSE:
$i = lossless_int($sth);
If ($i===false) {
// error out / provide
> On 22 Oct 2014, at 22:31, Stas Malyshev wrote:
>
> Hi!
>
>> Are you opposed to the existence of ext/filter given it has
>> FILTER_VALIDATE_INT, a “primitive for handling type conversions”?
>
> FILTER_VALIDATE_INT is an option for a filter_var function, and it is
> not introducing any new rul
Hi!
> Are you opposed to the existence of ext/filter given it has
> FILTER_VALIDATE_INT, a “primitive for handling type conversions”?
FILTER_VALIDATE_INT is an option for a filter_var function, and it is
not introducing any new rules for handling types in the engine. What you
are proposing is not
> On 22 Oct 2014, at 21:11, Stas Malyshev wrote:
>
>>> You propose to add completely new type conversion rules into the
>>> engine, in addition to ones already present and used there. It's
>>> not the same as merely changing how the engine internally runs
>>> pre-existing code. The new rules are
Hi,
On Sat, Oct 18, 2014 at 10:20 AM, Stas Malyshev wrote:
> Hi!
>
>> resurrecting this thread in the hope of getting a bit more feedback.
>
> About removing functions - I don't really see any particular win in it.
> I mean, we'd have enough BC concerns in PHP 7 without having to worry
> about mi
> On 21 Oct 2014, at 09:35, Dmitry Stogov wrote:
>
> I expect, it'll make some slowdown for all PHP scripts, independently, if
> they use BIGINT or not.
> I'll try to take a deeper look into the patch later...
>
> Could you provide some benchmark results, comparing your patch with master?
I f
Hi!
> Yes, that’s still merely an implementation detail. If HHVM decides to
> make explode() into an opcode, it’s not a language change. It is not
> any different if PHP does the same.
If HHVM decides to introduce new type handling rules, however, it is.
Even if they are going to be called using
QUERY_STRING is limited; but what about POST/etc.?
I think giving attackers a way to turn a variable into an array is a problem at
large.
On 22 Oct 2014, at 22:08, Anatol Belski wrote:
> On Wed, October 22, 2014 21:18, Daniel Zulla wrote:
>> What happens if you exceed uint32?
>>
>>
>> Just c
On Wed, October 22, 2014 21:18, Daniel Zulla wrote:
> What happens if you exceed uint32?
>
>
> Just curious, security-wise, because AFAIR exceeding uint32 would be
> possible through superglobals only, which a potential attacker could abuse.
>
>
> param=foo
>
> param[a]=foo¶m[b]=foo¶m[c]=foo¶m[…]=f
On Wed, Oct 22, 2014 at 9:35 PM, Daniel Zulla
wrote:
> OF COURSE IT’S NOT REALISTIC.
>
> But it’s a web security nightmare.
>
> Imagine a simple website accepting $_GET[‚test‘] as input. Now imagine a
> web attacker who converts the server-side variable into an array
> (?test[foo]) trying to INTE
On Wed, October 22, 2014 21:15, Nikita Popov wrote:
> On Wed, Oct 22, 2014 at 9:13 PM, Anatol Belski wrote:
>
>
>> Hi Nikita,
>>
>>
>> On Wed, October 22, 2014 19:44, Nikita Popov wrote:
>>
>>> On Wed, Oct 22, 2014 at 5:56 PM, Anatol Belski wrote:
>>>
>>>
>>>
Commit:a5e4f1f598f3a53e5793d
OF COURSE IT’S NOT REALISTIC.
But it’s a web security nightmare.
Imagine a simple website accepting $_GET[‚test‘] as input. Now imagine a web
attacker who converts the server-side variable into an array (?test[foo])
trying to INTENTIONALLY TRIGGER an overflow.
I’ve just tested it. It throws an
> On 22 Oct 2014, at 20:29, Stas Malyshev wrote:
>
>> No, it wouldn’t require a 2/3 majority. The optimisation me and
>> Dmitry are referring to is merely an optimisation, it’s an
>> implementation detail. This doesn’t touch any of the language spec or
>> the language as understood by users.
>
On Wed, Oct 22, 2014 at 9:18 PM, Daniel Zulla
wrote:
> What happens if you exceed uint32?
>
> Just curious, security-wise, because AFAIR exceeding uint32 would be
> possible through superglobals only, which a potential attacker could abuse.
>
> param=foo
>
> param[a]=foo¶m[b]=foo¶m[c]=foo¶m[…]=fo
Hi!
> No, it wouldn’t require a 2/3 majority. The optimisation me and
> Dmitry are referring to is merely an optimisation, it’s an
> implementation detail. This doesn’t touch any of the language spec or
> the language as understood by users.
Sorry, it's not "merely an optimization", it's making i
What happens if you exceed uint32?
Just curious, security-wise, because AFAIR exceeding uint32 would be possible
through superglobals only, which a potential attacker could abuse.
param=foo
param[a]=foo¶m[b]=foo¶m[c]=foo¶m[…]=foo (reaching uin32+1)
On 22 Oct 2014, at 21:15, Nikita Popov wrote
On Wed, Oct 22, 2014 at 9:13 PM, Anatol Belski wrote:
> Hi Nikita,
>
> On Wed, October 22, 2014 19:44, Nikita Popov wrote:
> > On Wed, Oct 22, 2014 at 5:56 PM, Anatol Belski wrote:
> >
> >
> >> Commit:a5e4f1f598f3a53e5793d290619806b41f1f1380
> >> Author:Anatol Belski Wed, 22 Oct
Hi Nikita,
On Wed, October 22, 2014 19:44, Nikita Popov wrote:
> On Wed, Oct 22, 2014 at 5:56 PM, Anatol Belski wrote:
>
>
>> Commit:a5e4f1f598f3a53e5793d290619806b41f1f1380
>> Author:Anatol Belski Wed, 22 Oct 2014 17:27:33
>> +0200
>> Parents: cccd538512c3d345a73eeb5f1cc29643a
On 22.10.2014 10:37, Bob Weinand wrote:
> I know we have that already discussed a lot now, but I’d like to expose my
> points on the return value here:
>
> I imagine code like (supposing that we ever will have scalar typehints):
>
> function acceptsInt (int $i = null) {
> if ($i === null) {
>
Zeev Suraski wrote on 22/10/2014 09:34:
If we called them something like lossless_float() - that provides developers
with the necessary heads-up that this will not use the standard conversion
rules they're familiar with. It also gives them a good indication as to how
it may be different from tho
> On 22 Oct 2014, at 09:17, Stas Malyshev wrote:
>
> If those are opcodes, those rules will require 2/3 majority for
> acceptance, since those will be the engine rules for type conversion,
> not just a set of functions. And, of course, the rules not matching the
> other engine rules for type con
> -Ursprüngliche Nachricht-
> Von: Weinand Bob [mailto:bobw...@hotmail.com]
> Gesendet: Mittwoch, 22. Oktober 2014 16:16
> An: Dmitry Stogov
> Cc: Andrea Faulds; PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
> If we really want an integer at all price we just can u
If we really want an integer at all price we just can use a simple (int) cast.
That’s AFAIK not the point of this RFC.
And at that point where we can add a default as second parameter, we also just
can use NULL with ??. The latter is at the same time more powerful and less
restrictive.
Also, w
for me it's weird that to_int() that must return "int" may return not "int".
NULL with ?? seems better than FALSE :)
but if we talk about safety, we should be able to relay on to_int() return
value without additional checks.
Thanks. Dmitry.
On Wed, Oct 22, 2014 at 4:35 PM, Weinand Bob wrote:
>
So, what exactly changes here if we have a second parameter or just return null
by default?
It doesn’t make any difference, it’s just another way to write it:
to_int($a, $default)
or
to_int($a) ?? $default
Also, if you want exceptions, you always can wrap a userland function around it
— but I’d
Hi Derick,
> On 21 Oct 2014, at 17:26, Derick Rethans wrote:
>
> But what about if we also would like a to_bool, which would accept
> "true", "false", "0", "1", true, false, 1 and 0?
Yep, I think that totally makes sense. "yes" and "no" would be further
candidates but that’s probably already
"null" or "false" return value would make these functions not really
useful, because they won't guarantee to return desired type.
printf("%d\n", to_int("abcd")); // will print 0
The only reliable option to support wrong input is exceptions.
On the other hand, exceptions maybe difficult to use or
hi,
On Tue, Oct 21, 2014 at 4:01 PM, Dmitry Stogov wrote:
> Hi Joe,
>
> As an extension it looks fine.
> I assume, you don't propose to use UString objects in engine and other
> extensions.
> Unfortunately, it's yet another incomplete solution.
I have to agree here.
As much as I like what has b
Hi!
> Thinking a bit more on this, if we don't want the 2/3 hurdle and perhaps
> make this a bit (or actually a lot) less controversial, we should change the
> names of these functions. to_float() strongly implies that this function
> represents PHP's standard typing ruleset, which these function
I know we have that already discussed a lot now, but I’d like to expose my
points on the return value here:
I imagine code like (supposing that we ever will have scalar typehints):
function acceptsInt (int $i = null) {
if ($i === null) {
$i = 2 /* default value */;
}
/* do so
> -Original Message-
> From: Zeev Suraski [mailto:z...@zend.com]
> Sent: Wednesday, October 22, 2014 11:26 AM
> To: 'Stas Malyshev'; 'Andrea Faulds'
> Cc: 'PHP Internals'
> Subject: RE: [PHP-DEV] [RFC] Safe Casting Functions
>
> > -Original Message-
> > From: Stas Malyshev [mailto:s
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Wednesday, October 22, 2014 11:18 AM
> To: Dmitry Stogov; Andrea Faulds
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
> Hi!
>
> >>> - it's probably make sense to implement these
Hi!
>>> - it's probably make sense to implement these function as a new
>> opcode(s) in VM
>>
>> That could be an optimisation later, yes. I note that you’ve added
>> function replacement with opcodes for certain commonly-used functions. We
>> could make these functions use that. Then they’d still
On 21 October 2014 23:21:37 GMT+01:00, Andrea Faulds wrote:
>Make array-like indexing with [] be by
>code points as you may be able to do that in constant time
If the internal representation is UTF8, both code point and grapheme access
require traversal unless you have some additional index s
On 21/10/14 23:51, Andrea Faulds wrote:
> I am gradually warming to throwing an exception. An interesting idea I’ve had
> suggested on Twitter was by Matt Parker, who suggested that I add an optional
> 2nd argument. Without the argument, it throws an exception. With an argument,
> it returns tha
On 21 October 2014 23:21:37 GMT+01:00, Andrea Faulds wrote:
>
>> On 21 Oct 2014, at 21:42, Rowan Collins
>wrote:
>>
>> The only case I can see where a default encoding would be sensible
>would be where source code itself is in a different encoding, so that
>u('literal string') works as expected.
On Wed, Oct 22, 2014 at 2:51 AM, Andrea Faulds wrote:
>
> > On 21 Oct 2014, at 10:14, Dmitry Stogov wrote:
> >
> > some notes:
> > - it's probably make sense to implement these function as a new
> opcode(s) in VM
>
> That could be an optimisation later, yes. I note that you’ve added
> function r
43 matches
Mail list logo
