Hi Stas,
On Thu, Nov 20, 2014 at 4:38 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Please refer to CWE/SANS TOP 25, Monster Mitigation especially.
http://cwe.mitre.org/top25/#Mitigations
and ISO 27000. (I cannot provide link to it, since one should buy the
document to read)
Hi!
Please refer to CWE/SANS TOP 25, Monster Mitigation especially.
http://cwe.mitre.org/top25/#Mitigations
and ISO 27000. (I cannot provide link to it, since one should buy the
document to read)
Could you please be more specific about how this relevant to this
specific case? But an ISO
Hi!
I brought up ISO 27000 as the definition of IT security, since there are
many
definition for security. ISO 27000 does not define what security
measure is,
That's exactly the issue. You bring a very generic definitions from
standards and best practices, and then you bring your personal
Hi Stas,
On Fri, Nov 21, 2014 at 1:54 AM, Stas Malyshev smalys...@gmail.com wrote:
Please refer to CWE/SANS TOP 25, Monster Mitigation especially.
http://cwe.mitre.org/top25/#Mitigations
and ISO 27000. (I cannot provide link to it, since one should buy the
document to read)
Could
Hi Andrea,
On Wed, November 19, 2014 04:07, Andrea Faulds wrote:
On 19 Nov 2014, at 03:02, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I would like to have DbC to harden app security as well.
I'm looking for something like D language.
http://dlang.org/contracts.html
With DbC, checking
On 19 Nov 2014, at 08:33, Anatol Belski anatol@belski.net wrote:
while briefly looking through the conversion examples, i see some weird
results
string(5) “31e+7” - shouldn't this be valid for int?
The trend seems to be to consider things with exponents or decimal points as
floats.
On Wed, November 19, 2014 15:49, Andrea Faulds wrote:
On 19 Nov 2014, at 08:33, Anatol Belski anatol@belski.net wrote:
while briefly looking through the conversion examples, i see some weird
results
string(5) “31e+7” - shouldn't this be valid for int?
The trend seems to be to
On 19 Nov 2014, at 18:28, Anatol Belski anatol@belski.net wrote:
On Wed, November 19, 2014 15:49, Andrea Faulds wrote:
On 19 Nov 2014, at 08:33, Anatol Belski anatol@belski.net wrote:
object(Stringable)#2 (0) {} - and similar actually, what if _toString()
returns some int/float
On Wed, November 19, 2014 19:47, Andrea Faulds wrote:
__toString() always errors if it doesn’t return a string, I see no
reason to change that.
But in the other cases it converts strings to numbers. I mean like
class A {function __toString(){return '10';}} $a = (string) (new A);
//numeric
On 19 Nov 2014, at 19:04, Anatol Belski anatol@belski.net wrote:
Yeah, try_string(new A) == (string)(new A), but try_int(new A) !=
(int)(string)(new A) in the RFC. Whereby '10' were pretty valid for int,
no?
Oh, you’re saying how to_int/to_float don’t accept __toString objects. I
Hi!
I like this RFC overall. Precise parameter checks is good for security
always.
I don't see how it matters for security at all. If you need an int,
(int) works as well as any proposed check, security-wise. You may want
different diagnostics, etc. but this doesn't have to do much with
Hi Stas,
On Thu, Nov 20, 2014 at 10:28 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
I like this RFC overall. Precise parameter checks is good for security
always.
I don't see how it matters for security at all. If you need an int,
(int) works as well as any proposed check,
Hi Stas,
On Thu, Nov 20, 2014 at 4:10 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Please refer to CWE/SANS TOP 25, Monster Mitigation especially.
http://cwe.mitre.org/top25/#Mitigations
and ISO 27000. (I cannot provide link to it, since one should buy the
document to read)
Programmer
Hi!
Please refer to CWE/SANS TOP 25, Monster Mitigation especially.
http://cwe.mitre.org/top25/#Mitigations
and ISO 27000. (I cannot provide link to it, since one should buy the
document to read)
Could you please be more specific about how this relevant to this
specific case? But an ISO
On 20/11/14 07:29, Yasuo Ohgaki wrote:
$id = $_GET['id'];
pg_qeury(SELECT * FROM some_table WHERE id = $id;);
Anybody using that method of passing parameters to a database needs much
better education. This particular proposal just adds yet another 'how
not to' rather than actually fixing the
Hi Andrea,
On Tue, Oct 21, 2014 at 7:57 AM, Andrea Faulds a...@ajf.me wrote:
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
I like this RFC overall. Precise parameter checks is good for security
always.
I
On 19 Nov 2014, at 03:02, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I would like to have DbC to harden app security as well.
I'm looking for something like D language.
http://dlang.org/contracts.html
With DbC, checking parameter types/range/etc happen only when development.
Therefore,
On 20 Oct 2014, at 23:57, Andrea Faulds a...@ajf.me wrote:
Good evening,
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
Thanks!
After some discussions, the RFC has been revised
On 24.10.2014 20:54, Andrea Faulds wrote:
On 24 Oct 2014, at 19:52, Marc Bennewitz php@mabe.berlin wrote:
Floats are special, they are not expected to be precise. If we reject this,
then perhaps we should also reject 0.1, because it can’t be precisely
represented by a float?
It's a
On 24.10.2014 01:53, Andrea Faulds wrote:
On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote:
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
|to_float(||9223372036854774784) - pass |as it results in
9223372036854774784
On 24 Oct 2014, at 19:06, Marc Bennewitz php@mabe.berlin wrote:
On 24.10.2014 01:53, Andrea Faulds wrote:
On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote:
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
On 24.10.2014 20:13, Andrea Faulds wrote:
On 24 Oct 2014, at 19:06, Marc Bennewitz php@mabe.berlin wrote:
On 24.10.2014 01:53, Andrea Faulds wrote:
On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote:
You addresses data loss on convert float to int.
Do you also address data
On 24 Oct 2014, at 19:52, Marc Bennewitz php@mabe.berlin wrote:
Floats are special, they are not expected to be precise. If we reject this,
then perhaps we should also reject 0.1, because it can’t be precisely
represented by a float?
It's a difference casting string to float or int to
Marc Bennewitz wrote on 22/10/2014 20:12:
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 =
I really like the strictness of this casting rules except of 010 will
be a valid integer / float.
As of you don't allow 0x and trailing white spaces as valid numbers
and don't allow floating like syntax as integers even if it result in
mathematical integer.
Allowing prefixed 0 as valid numbers
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
|to_float(||9223372036854774784) - pass |as it results in
9223372036854774784
|to_float(|||9223372036854774785|) - |failas it results in
9223372036854774784
|
Marc
|
On 23.10.2014 21:40, Marc
On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote:
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
|to_float(||9223372036854774784) - pass |as it results in
9223372036854774784
|to_float(|||9223372036854774785|) - |failas
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/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
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
-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:smalys
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
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
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!
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 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
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 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
To: Bob Weinand
Cc: Andrea Faulds; PHP Internals
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
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
-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 smalys
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 smalys
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
On 21/10/14 02:17, Andrea Faulds wrote:
JavaScript returns NaN here and C sets errno to an error value. PHP uses
FALSE, in some respects, like JavaScript uses NaN.
Isn't part of the problem here that we DO need more than a single return
in many places. Even 'bool' can be thought off as three
Both, the idea and implementation look fine.
Personally, I hate the existing type conversion rules, and I would like to
use something like this by default (may be with exception for
null/false/true handling), but it may be a big compatibility break, so
introducing to_int() is better than nothing.
Hello, internals!
Good evening,
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
Personally I don't like this RFC because it's introducing one more way
to cast value in PHP. We already
On Mon, 20 Oct 2014, Andrea Faulds wrote:
Good evening,
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
The functions return FALSE on failure instead of NULL because:
- If strict
On Oct 20, 2014, at 6:17 PM, Andrea Faulds a...@ajf.me wrote:
On 21 Oct 2014, at 02:07, Josh Watzman jwatz...@fb.com wrote:
Throwing an exception or even returning NULL seems so much better than
returning false -- false is a boolean, not an error, and despite some
historical cases of PHP
On 21/10/2014 02:48, Stas Malyshev wrote:
It would be possible to make to_int() merely an alias of
filter_var(…, FILTER_VALIDATE_INT). Though that would make it depend
on ext/filter or otherwise duplicate functionality.
You seem to sound like depending on something already existing in PHP is
a
On 21/10/2014 02:17, Andrea Faulds wrote:
There isn’t a lack of a value, there’s no value.
You might want to consider re-wording that. It comes across as rather an
oxymoron...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
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 added function
replacement with opcodes for certain commonly-used
On 21 Oct 2014, at 22:01, Rowan Collins rowan.coll...@gmail.com wrote:
On 21/10/2014 02:17, Andrea Faulds wrote:
There isn’t a lack of a value, there’s no value.
You might want to consider re-wording that. It comes across as rather an
oxymoron…
Oh dear, I repeated myself accidentally.
Good evening,
I am presenting a new RFC to add a set of three functions to do validated casts
for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
In general I like this RFC.
I don't see why to_string would not accept and cast integers and floats to
strings. And even if there is a valid reason it is not mentioned.
If this gets accepted you should consider the naming in the user
documentation. Beginners should not consider these functions
On 21 Oct 2014, at 00:16, Haralan Dobrev hkdob...@gmail.com wrote:
In general I like this RFC.
I don't see why to_string would not accept and cast integers and floats to
strings. And even if there is a valid reason it is not mentioned.
It does accept and cast integers and floats to
Hi Andrea,
On 21 Oct 2014, at 00:57, Andrea Faulds a...@ajf.me wrote:
Good evening,
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
I like the proposal except for one thing: the
On 21 Oct 2014, at 00:27, Lars Strojny l...@strojny.net wrote:
I like the proposal except for one thing: the functions returning false in
case of an error. As the next logical function would be to_bool(), I
foresee a lot of trouble with regards to API design as returning false there
Hi!
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
The main problem that happened with scalar typing RFC remains here:
third set of rules for casting types. Of course, since it's just
Hi!
On 21 Oct 2014, at 01:32, Stas Malyshev smalys...@sugarcrm.com wrote:
The main problem that happened with scalar typing RFC remains here:
third set of rules for casting types. Of course, since it's just
functions and not language constructs, we can have a set of functions
for any set
On Oct 20, 2014, at 3:57 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
Thanks!
I think this is pretty cool, but I'm really
Hi!
Wait, we actually already have FILTER_VALIDATE_INT and
FILTER_VALIDATE_FLOAT,
Actually, to_int is very close to FILTER_VALIDATE_INT, and I’m not
sure, but I think to_float may be close to FILTER_VALIDATE_FLOAT. The
main difference with integers is rejection of whitespace and
On 21 Oct 2014, at 02:07, Josh Watzman jwatz...@fb.com wrote:
Throwing an exception or even returning NULL seems so much better than
returning false -- false is a boolean, not an error, and despite some
historical cases of PHP using false as a poor person's error code, it
really isn’t.
On 21 Oct 2014, at 02:08, Stas Malyshev smalys...@sugarcrm.com wrote:
Actually, to_int is very close to FILTER_VALIDATE_INT, and I’m not
sure, but I think to_float may be close to FILTER_VALIDATE_FLOAT. The
main difference with integers is rejection of whitespace and
toString-able objects.
Hi!
No, not quite. One of the nice things about rejecting whitespace is
it lets you handle it however you want. Want to reject all
whitespace? to_int($foo). Want to accept all whitespace?
to_int(trim($foo)). Want to trim only tabs? to_int(trim($foo, “\t”)).
This is actually allows more
77 matches
Mail list logo
