# FILTER_VALIDATE_INT and +0/-0 - Thread: https://externals.io/message/65577 - Original archive: https://news-web.php.net/php.internals/65577 - Started by Martin Jansen on 2013-02-03T18:15:59+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #65577 — Martin Jansen — 2013-02-03T18:15:59+00:00 URL: https://externals.io/message/65577#65577 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 --- ## #65579 — Sherif Ramadan — 2013-02-03T18:34:54+00:00 URL: https://externals.io/message/65577#65579 · In reply to: #65577 > 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. --- ## #65594 — Derick Rethans — 2013-02-03T22:38:16+00:00 URL: https://externals.io/message/65577#65594 · In reply to: #65577 > 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 --- ## #65622 — Patrick Schaaf — 2013-02-04T09:50:40+00:00 URL: https://externals.io/message/65577#65622 · In reply to: #65594 > +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 --- ## #65628 — Frank Liepert — 2013-02-04T11:14:50+00:00 URL: https://externals.io/message/65577#65628 · In reply to: #65622 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_INT` should 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 --- ## #65629 — Gustavo Lopes — 2013-02-04T11:32:42+00:00 URL: https://externals.io/message/65577#65629 · In reply to: #65628 On Mon, 04 Feb 2013 12:14:50 +0100, Frank Liepert wrote: > 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_INT` should 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 --- ## #65630 — Pierre Joye — 2013-02-04T11:40:40+00:00 URL: https://externals.io/message/65577#65630 · In reply to: #65629 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 --- ## #65634 — Frank Liepert — 2013-02-04T13:27:01+00:00 URL: https://externals.io/message/65577#65634 · In reply to: #65629 > 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) --- ## #65640 — Brian Moon — 2013-02-04T17:28:00+00:00 URL: https://externals.io/message/65577#65640 · In reply to: #65634 > 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) 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 --- ## #65729 — hakre — 2013-02-08T19:04:35+00:00 URL: https://externals.io/message/65577#65729 · In reply to: #65629 ----- Ursprüngliche Message ----- > Von: Gustavo Lopes > An: 'Patrick Schaaf' ; internals@lists.php.net; Frank Liepert > CC: 'Derick Rethans' ; 'Martin Jansen' > Gesendet: 12:32 Montag, 4.Februar 2013 > Betreff: Re: AW: [PHP-DEV] `FILTER_VALIDATE_INT` and +0/-0 > > 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). 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 --- ## #65730 — Gustavo Lopes — 2013-02-08T20:19:46+00:00 URL: https://externals.io/message/65577#65730 · In reply to: #65729 > ----- Ursprüngliche Message ----- > > […] > > 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_INT` should reflect hidden > dependency of input encoding here. I'm not sure what you're arguing for here. -- Gustavo Lopes --- ## #65733 — hakre — 2013-02-08T21:09:22+00:00 URL: https://externals.io/message/65577#65733 · In reply to: #65730 ----- Ursprüngliche Message ----- > Von: Gustavo Lopes > An: 'Patrick Schaaf' ; "internals@lists.php.net" ; Frank Liepert ; hakre > CC: 'Derick Rethans' ; 'Martin Jansen' > Gesendet: 21:19 Freitag, 8.Februar 2013 > Betreff: Re: AW: [PHP-DEV] `FILTER_VALIDATE_INT` and +0/-0 > > > […] > 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? > > > […] > "+" 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. > > 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 the `FILTER_VALIDATE_INT` won'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 --- ## #65735 — Gustavo Lopes — 2013-02-08T21:35:01+00:00 URL: https://externals.io/message/65577#65735 · In reply to: #65733 > ----- Ursprüngliche Message ----- > > […] > > 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 --- ## #65736 — Derick Rethans — 2013-02-08T22:12:08+00:00 URL: https://externals.io/message/65577#65736 · In reply to: #65729 > Von: Gustavo Lopes > > > […] > > 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