On Wed, Oct 22, 2014 at 2:51 AM, Andrea Faulds a...@ajf.me wrote:
On 21 Oct 2014, at 10:14, Dmitry Stogov dmi...@zend.com 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
On 21 October 2014 23:21:37 GMT+01:00, Andrea Faulds a...@ajf.me wrote:
On 21 Oct 2014, at 21:42, Rowan Collins rowan.coll...@gmail.com
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
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 that
On 21 October 2014 23:21:37 GMT+01:00, Andrea Faulds a...@ajf.me 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
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 be usable
-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 function as
-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
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
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 functions
hi,
On Tue, Oct 21, 2014 at 4:01 PM, Dmitry Stogov dmi...@zend.com 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
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 Derick,
On 21 Oct 2014, at 17:26, Derick Rethans der...@php.net 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
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
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
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,
-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 use a
On 22 Oct 2014, at 09:17, Stas Malyshev smalys...@sugarcrm.com 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
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
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) {
Hi Nikita,
On Wed, October 22, 2014 19:44, Nikita Popov wrote:
On Wed, Oct 22, 2014 at 5:56 PM, Anatol Belski a...@php.net wrote:
Commit:a5e4f1f598f3a53e5793d290619806b41f1f1380
Author:Anatol Belski a...@php.net Wed, 22 Oct 2014 17:27:33
+0200
Parents:
On Wed, Oct 22, 2014 at 9:13 PM, Anatol Belski a...@php.net wrote:
Hi Nikita,
On Wed, October 22, 2014 19:44, Nikita Popov wrote:
On Wed, Oct 22, 2014 at 5:56 PM, Anatol Belski a...@php.net wrote:
Commit:a5e4f1f598f3a53e5793d290619806b41f1f1380
Author:Anatol Belski
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]=fooparam[b]=fooparam[c]=fooparam[…]=foo (reaching uin32+1)
On 22 Oct 2014, at 21:15, Nikita
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 it an
On Wed, Oct 22, 2014 at 9:18 PM, Daniel Zulla daniel.zu...@gmail.com
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
On 22 Oct 2014, at 20:29, Stas Malyshev smalys...@sugarcrm.com 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
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
On Wed, October 22, 2014 21:15, Nikita Popov wrote:
On Wed, Oct 22, 2014 at 9:13 PM, Anatol Belski a...@php.net wrote:
Hi Nikita,
On Wed, October 22, 2014 19:44, Nikita Popov wrote:
On Wed, Oct 22, 2014 at 5:56 PM, Anatol Belski a...@php.net wrote:
Commit:
On Wed, Oct 22, 2014 at 9:35 PM, Daniel Zulla daniel.zu...@gmail.com
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
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
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 a...@php.net wrote:
On Wed, October 22, 2014 21:18, Daniel Zulla wrote:
What happens if you exceed uint32?
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 (
On 21 Oct 2014, at 09:35, Dmitry Stogov dmi...@zend.com 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
Hi,
On Sat, Oct 18, 2014 at 10:20 AM, Stas Malyshev smalys...@sugarcrm.com 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
On 22 Oct 2014, at 21:11, Stas Malyshev smalys...@sugarcrm.com 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
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 22:31, Stas Malyshev smalys...@sugarcrm.com 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
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 /
-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
Hi,
On Thu, Oct 23, 2014 at 1:01 AM, Zeev Suraski z...@zend.com 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
-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
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 in
-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, it's
On Thu, Oct 23, 2014 at 1:34 AM, Zeev Suraski z...@zend.com 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]
43 matches
Mail list logo
