Hi Stas,
On Fri, Nov 21, 2014 at 1:54 AM, Stas Malyshev 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 you ple
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 pers
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
Hi Stas,
On Thu, Nov 20, 2014 at 4:38 PM, Stanislav Malyshev
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 yo
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!
> 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 a
Hi Stas,
On Thu, Nov 20, 2014 at 4:10 PM, Yasuo Ohgaki 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 should control
Hi Stas,
On Thu, Nov 20, 2014 at 10:28 AM, Stanislav Malyshev
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, security-wise. You may
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
secur
> On 19 Nov 2014, at 19:04, Anatol Belski 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
suppose they could, b
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);
>> //
> On 19 Nov 2014, at 18:28, Anatol Belski wrote:
>
> On Wed, November 19, 2014 15:49, Andrea Faulds wrote:
>>
>>> On 19 Nov 2014, at 08:33, Anatol Belski wrote:
>>> object(Stringable)#2 (0) {} - and similar actually, what if _toString()
>>> returns some int/float literal? that should pass as w
On Wed, November 19, 2014 15:49, Andrea Faulds wrote:
>
>> On 19 Nov 2014, at 08:33, Anatol Belski 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 t
> On 19 Nov 2014, at 08:33, Anatol Belski 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. Even though ther
Hi Andrea,
On Wed, November 19, 2014 04:07, Andrea Faulds wrote:
>
>> On 19 Nov 2014, at 03:02, Yasuo Ohgaki 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 03:02, Yasuo Ohgaki 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, app runs fas
Hi Andrea,
On Tue, Oct 21, 2014 at 7:57 AM, Andrea Faulds 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 would
> On 20 Oct 2014, at 23:57, 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.
>
> 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 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
> On 24 Oct 2014, at 19:52, Marc Bennewitz 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 float.
> Flo
On 24.10.2014 20:13, Andrea Faulds wrote:
>> On 24 Oct 2014, at 19:06, Marc Bennewitz wrote:
>>
>>
>> On 24.10.2014 01:53, Andrea Faulds wrote:
On 23 Oct 2014, at 20:50, Marc Bennewitz wrote:
You addresses data loss on convert float to int.
Do you also address data loss on in
> On 24 Oct 2014, at 19:06, Marc Bennewitz wrote:
>
>
> On 24.10.2014 01:53, Andrea Faulds wrote:
>>> On 23 Oct 2014, at 20:50, Marc Bennewitz wrote:
>>>
>>> You addresses data loss on convert float to int.
>>> Do you also address data loss on int to float?
>>>
>>> |to_float(||92233720368547
On 24.10.2014 01:53, Andrea Faulds wrote:
>> On 23 Oct 2014, at 20:50, Marc Bennewitz 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_floa
> On 23 Oct 2014, at 20:50, Marc Bennewitz 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 it res
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 Benn
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 numbe
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 =
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
> -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
>
> > Whil
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
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
: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Wednesday, October 22, 2014 1:28 PM
> 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 real
> 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!
> 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 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.
>
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
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
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!
> 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: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&#
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/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 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
> On 21 Oct 2014, at 22:01, Rowan Collins 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. I think I meant
> 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
replacement with opcodes for certain commonly-used functions. We cou
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: http://www
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 Oct 20, 2014, at 6:17 PM, Andrea Faulds wrote:
>> On 21 Oct 2014, at 02:07, Josh Watzman 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"
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:
> > -
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 alr
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.
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
On Oct 20 2014, at 8:07 PM, Josh Watzman wrote:
> I think this is pretty cool, but I'm really worried about some of its typing
> implications. In particular:
>
>> The functions return FALSE on failure instead of NULL because:
>
> Throwing an exception or even returning NULL seems so much better
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 f
> On 21 Oct 2014, at 02:08, Stas Malyshev 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.
>
> So esse
> On 21 Oct 2014, at 02:07, Josh Watzman 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.
Why
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 Oct 20, 2014, at 3:57 PM, 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.
>
> Thanks!
I think this is pretty cool, but I'm really worrie
Hi!
> On 21 Oct 2014, at 01:32, Stas Malyshev 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 of casting rules
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 "
> On 21 Oct 2014, at 00:27, Lars Strojny 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
> either means
Hi Andrea,
> On 21 Oct 2014, at 00:57, 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.
I like the proposal except for one thing: the fun
> On 21 Oct 2014, at 00:16, Haralan Dobrev 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 strings… I made a
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 "s
76 matches
Mail list logo
