Back in December I submitted a pull request to make FILTER_VALIDATE_INT
accept +0/-0. That request was merged into php-src:
https://github.com/php/php-src/pull/248
The other day I then stumbled upon a note on
http://www.php.net/manual/en/filter.filters.validate.php saying "Numbers
+0 and -0 are not valid integers but validate as floats.", which makes
me wonder if the previous behavior (rejecting +0/-0) was on purpose
rather than by mistake?
Or should the documentation be adjusted to reflect the new behavior?
- Martin
Back in December I submitted a pull request to make
FILTER_VALIDATE_INT
accept +0/-0. That request was merged into php-src:https://github.com/php/php-src/pull/248
The other day I then stumbled upon a note on
http://www.php.net/manual/en/filter.filters.validate.php saying "Numbers
+0 and -0 are not valid integers but validate as floats.", which makes
me wonder if the previous behavior (rejecting +0/-0) was on purpose
rather than by mistake?Or should the documentation be adjusted to reflect the new behavior?
- Martin
--
Well, as far as I can tell that note was there back when
FILTER_VALIDATE_INT didn't accept +/-0 as a valid int. I'll go ahead and
update the docs to note the change in behavior.
Back in December I submitted a pull request to make
FILTER_VALIDATE_INT
accept +0/-0. That request was merged into php-src:https://github.com/php/php-src/pull/248
The other day I then stumbled upon a note on
http://www.php.net/manual/en/filter.filters.validate.php saying "Numbers
+0 and -0 are not valid integers but validate as floats.", which makes
me wonder if the previous behavior (rejecting +0/-0) was on purpose
rather than by mistake?
+0 and -0 don't make sense for integers, where there is only 0. Allowing
only 0 was on purpose.
Derick
+0 and -0 don't make sense for integers, where there is only 0. Allowing
only 0 was on purpose.
+0 and -0 are accepted by sscanf('%d'), intval(), and (int).
+0 is produced by sprintf('%+d')
Thus, the change to FILTER_VALIDATE_INT seems to make sense.
best regards
Patrick
The change to FILTER_VALIDATE_INT seems to be inconsistent.
First of all, take the following bug (https://bugs.php.net/bug.php?id=54096) where it says "PHP defines -0 as an int.". Where does PHP define it? The documentation says: "An integer is a number of the set ℤ = {..., -2, -1, 0, 1, 2, ...}."
Secondly, try the following code: var_dump(round(-0.1));
What is the result? Surprise: float(-0)
And it is not a bug (https://bugs.php.net/bug.php?id=42477)
To sum it up:
-
FILTER_VALIDATE_INTshould never treat "+0" or "-0" as valid integers. - Instead, var_dump needs to be corrected.
- It could be even gone further in adding support for signed zero arithmetic (see IEEE754).
Kind regards,
Frank
-----Ursprüngliche Nachricht-----
Von: Patrick Schaaf [mailto:php@bof.de]
Gesendet: Montag, 4. Februar 2013 10:51
An: internals@lists.php.net
Cc: Derick Rethans; Martin Jansen
Betreff: Re: [PHP-DEV] FILTER_VALIDATE_INT and +0/-0
+0 and -0 don't make sense for integers, where there is only 0.
+Allowing
only 0 was on purpose.
+0 and -0 are accepted by sscanf('%d'), intval(), and (int).
+0 is produced by sprintf('%+d')
Thus, the change to FILTER_VALIDATE_INT seems to make sense.
best regards
Patrick
On Mon, 04 Feb 2013 12:14:50 +0100, Frank Liepert Frank.Liepert@gmx.de
wrote:
The change to
FILTER_VALIDATE_INTseems to be inconsistent.First of all, take the following bug
(https://bugs.php.net/bug.php?id=54096) where it says "PHP defines -0 as
an int.". Where does PHP define it? The documentation says: "An integer
is a number of the set ℤ = {..., -2, -1, 0, 1, 2, ...}."Secondly, try the following code: var_dump(round(-0.1));
What is the result? Surprise: float(-0)
And it is not a bug (https://bugs.php.net/bug.php?id=42477)To sum it up:
FILTER_VALIDATE_INTshould never treat "+0" or "-0" as valid integers.- Instead, var_dump needs to be corrected.
- It could be even gone further in adding support for signed zero
arithmetic (see IEEE754).
You're confusing things. Floats are irrelevant to this discussion. It's
clear -0. (float) does exist and has a well defined meaning. The situation
is manifestly different for integers because there are no separate
positive and negative 0 integers in most likely all the architectures PHP
runs on.
So the question is only whether "+0" or "-0" (or "+0", etc.) should be
accepted as integers by FILTER_VALIDATE_INT. I think they should, because
we also accept non-canonical inputs such as "+5", i.e., we always accept a
sign. It's true that 0 is neither positive or negative, but I don't think
"accepts a leading sign, except if it's 0" is a good option. It's an
unnecessary special case.
Finally, please don't top post. See
http://lxr.php.net/xref/PHP_TRUNK/README.MAILINGLIST_RULES#67
--
Gustavo Lopes
Hi,
So the question is only whether "+0" or "-0" (or "+0", etc.) should be
accepted as integers by FILTER_VALIDATE_INT. I think they should, because
we also accept non-canonical inputs such as "+5", i.e., we always accept a
sign. It's true that 0 is neither positive or negative, but I don't think
"accepts a leading sign, except if it's 0" is a good option. It's an
unnecessary special case.
I fully agree.
Cheers,
Pierre
So the question is only whether "+0" or "-0" (or "+0", etc.) should be
accepted as integers by FILTER_VALIDATE_INT. I think they should,
because
we also accept non-canonical inputs such as "+5", i.e., we always
accept a
sign. It's true that 0 is neither positive or negative, but I don't
think
"accepts a leading sign, except if it's 0" is a good option. It's an
unnecessary special case.
I was misguided by two statements, I'm sorry.
The 1st: In my opinion FILTER_VALIDATE_INT must work like var_dump(-0); (BR #54096)
The 2nd: "Treat "+0" and "-0" as valid integers just like var_dump() does." (https://github.com/php/php-src/pull/248)
Both statements are wrong, since the purpose of the filter extension is to validate strings. I found this information in BR #52884 (see last comment). Maybe it should be added to the docs? It's nonsense to say, that FILTER_VALIDATE_INT must work like var_dump() since they are both serving different purposes.
With this information I agree on your opinion.
var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // int(0) instead of the prior bool(false)
var_dump('-0'); // string(2) "-0"
var_dump(is_int('-0')); // bool(false)
Both statements are wrong, since the purpose of the filter extension
is to validate strings. I found this information in BR #52884 (see
last comment). Maybe it should be added to the docs? It's nonsense to
say, thatFILTER_VALIDATE_INTmust work likevar_dump()since they
are both serving different purposes.With this information I agree on your opinion.
var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // int(0) instead of
the prior bool(false) var_dump('-0'); // string(2) "-0"
var_dump(is_int('-0')); // bool(false)
var_dump does not attempt to convert a string into an integer when
possible. FILTER_VALIDATE_INT does. This is much more analagous to
FILTER_VALIDATE_INT IMO.
$ php -r "echo (is_numeric('-0')) ? (int)'-0' : null;"
0
I am not intimately familiar with the internals of filter, but I
replaced code in userland like this with filter calls.
Brian Moon
----- Ursprüngliche Message -----
Von: Gustavo Lopes glopes@nebm.ist.utl.pt
An: 'Patrick Schaaf' php@bof.de; internals@lists.php.net; Frank Liepert Frank.Liepert@gmx.de
CC: 'Derick Rethans' derick@php.net; 'Martin Jansen' martin@divbyzero.net
Gesendet: 12:32 Montag, 4.Februar 2013
Betreff: Re: AW: [PHP-DEV]FILTER_VALIDATE_INTand +0/-0So the question is only whether "+0" or "-0" (or
"+0", etc.) should be accepted as integers by FILTER_VALIDATE_INT. I
think they should, because we also accept non-canonical inputs such as
"+5", i.e., we always accept a sign. It's true that 0 is neither
positive or negative, but I don't think "accepts a leading sign, except
if it's 0" is a good option. It's an unnecessary special case.
A special case still left is "±0". It is with the 'PLUS-MINUS SIGN' (U+00B1).
It's an equally incorrect sign for the number 0 as "-" or "+" is incorrect. Available in internet standards ISO-8859-1 and more as "\xB1" (UTF-8 as "\xC2\xB1"), FILTER_VALIDATE_INT should reflect hidden dependency of input encoding here.
My ±0*2 cents here.
-- hakre
----- Ursprüngliche Message -----
Von: Gustavo Lopes glopes@nebm.ist.utl.pt
So the question is only whether "+0" or "-0" (or
"+0", etc.) should be accepted as integers by FILTER_VALIDATE_INT. I
think they should, because we also accept non-canonical inputs such as
"+5", i.e., we always accept a sign. It's true that 0 is neither
positive or negative, but I don't think "accepts a leading sign, except
if it's 0" is a good option. It's an unnecessary special case.A special case still left is "±0". It is with the 'PLUS-MINUS SIGN'
(U+00B1).
By special case, I meant a deviation to the general rule on how the code
handles the input. The code handles the characters 0-9 prefixed by an
optional sign. The PLUS-MINUS SIGN -- or, for that matter, all the other
numeric characters in the Unicode repertoire -- are irrelevant.
It's an equally incorrect sign for the number 0 as "-" or "+" is
incorrect. Available in internet standards ISO-8859-1 and more as
"\xB1" (UTF-8 as "\xC2\xB1"),FILTER_VALIDATE_INTshould reflect hidden
dependency of input encoding here.
I'm not sure what you're arguing for here.
--
Gustavo Lopes
----- Ursprüngliche Message -----
Von: Gustavo Lopes glopes@nebm.ist.utl.pt
An: 'Patrick Schaaf' php@bof.de; "internals@lists.php.net" internals@lists.php.net; Frank Liepert Frank.Liepert@gmx.de; hakre hanskrentel@yahoo.de
CC: 'Derick Rethans' derick@php.net; 'Martin Jansen' martin@divbyzero.net
Gesendet: 21:19 Freitag, 8.Februar 2013
Betreff: Re: AW: [PHP-DEV]FILTER_VALIDATE_INTand +0/-0
A special case still left is "±0". It is with the 'PLUS-MINUS
SIGN' (U+00B1).By special case, I meant a deviation to the general rule on how the code handles
the input. The code handles the characters 0-9 prefixed by an optional sign.
The general rule is to either allow + 'PLUS SIGN' (U+002B) and - 'HYPHEN-MINUS' (U+002D) for all positive natural numbers excluding zero.
The discussion is about to allow those as well for zero.
The 'PLUS-MINUS SIGN' (U+00B1) is a relevant sign for the number zero in this context but it got unnoticed so far in the discussion.
To not deviate from the general rule to allow signs in front of all positive natural numbers excluding zero for the missing zero, all valid plus and minus signs including both at once as possible for zero should be properly filtered as valid integers.
If you aim to have UTF-8 compatibility with the input, you should also consider 'MINUS SIGN' (U+2212), I didn't mention it so far because PHP by default targets ISO-8859-1 (at least commonly, historically and by popularity), so I only covered the sign in Latin-1.
The
PLUS-MINUS SIGN -- or, for that matter, all the other numeric characters in the
Unicode repertoire -- are irrelevant.
Unicode is never irrelevant, it's used to communicate clearly and specifically about which signs I'm concerned about.
Unicode does not classify "numeric characters", you probably meant 'Number, Decimal Digit', 'Symbol, Math [Sm]', 'Punctuation, Dash' or 'Number, Other' but it remains unspecified in your email. Would you please elaborate?
It's an equally incorrect sign for the number 0 as "-" or
"+" is incorrect. Available in internet standards ISO-8859-1 and more
as "\xB1" (UTF-8 as "\xC2\xB1"),
FILTER_VALIDATE_INTshould reflect hidden dependency of input encoding here.I'm not sure what you're arguing for here.
To make the feature complete, the input encoding needs to be hinted for those signs otherwise theFILTER_VALIDATE_INTwon't work properly with strings with an unexpected encoding (UTF-8 since PHP 5.4 (?!); ISO-8859-1 in the past).
Otherwise I'd say it's important to document a note that the function is US-ASCII / ISO-8859-1 safe (only?) as this is string input validation.
-- hakre
----- Ursprüngliche Message -----
Von: Gustavo Lopes glopes@nebm.ist.utl.pt
A special case still left is "±0". It is with the 'PLUS-MINUS
SIGN' (U+00B1).By special case, I meant a deviation to the general rule on how the
code handles the input. The code handles the characters 0-9 prefixed by
an optional sign.The general rule is to either allow + 'PLUS SIGN' (U+002B) and -
'HYPHEN-MINUS' (U+002D) for all positive natural numbers excluding zero.The discussion is about to allow those as well for zero.
I was explaining what I meant by "special rule" (read the context), not
describing any concrete implementation. If you fail to see how a general
rule that does not include the (IMO completely unnecessary) zero exclusion
is simpler and therefore a priori preferable, I surely won't be able to
convince you.
The 'PLUS-MINUS SIGN' (U+00B1) is a relevant sign for the number zero in
this context but it got unnoticed so far in the discussion.[...]
Unicode is never irrelevant, it's used to communicate clearly and
specifically about which signs I'm concerned about.Unicode does not classify "numeric characters", you probably meant
'Number, Decimal Digit', 'Symbol, Math [Sm]', 'Punctuation, Dash' or
'Number, Other' but it remains unspecified in your email. Would you
please elaborate?
Elaborating is not necessary. The whole issue is irrelevant. This filter
was never meant to handle anything but those ASCII characters. From I can
tell from the docs, the only filters that deal with anything else are
FILTER_SANITIZE_FULL_SPECIAL_CHARS (uses default_charset),
FILTER_SANITIZE_STRING and FILTER_UNSAFE_RAW with ENCODE_HIGH (which seem
to assume ISO-8859-1). Does this mean ext/filter sucks? To a certain
extent.
Otherwise I'd say it's important to document a note that the function is
US-ASCII / ISO-8859-1 safe (only?) as this is string input validation.
Feel free to fix the docs or open a bug report.
--
Gustavo Lopes
Von: Gustavo Lopes glopes@nebm.ist.utl.pt
So the question is only whether "+0" or "-0" (or
"+0", etc.) should be accepted as integers by FILTER_VALIDATE_INT. I
think they should, because we also accept non-canonical inputs such as
"+5", i.e., we always accept a sign. It's true that 0 is neither
positive or negative, but I don't think "accepts a leading sign, except
if it's 0" is a good option. It's an unnecessary special case.A special case still left is "±0". It is with the 'PLUS-MINUS SIGN' (U+00B1).
PHP can't parse that as a number, so forget about adding this.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine