Bug #68551 [Opn->Nab]: filter_var return false for (float) $integer if strlen($integer) > ini_get('prec

From: Date: Wed, 31 Mar 2021 14:29:21 +0000
Subject: Bug #68551 [Opn->Nab]: filter_var return false for (float) $integer if strlen($integer) > ini_get('prec
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-233100@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68551&edit=1

 ID:                 68551
 Updated by:         cmb@php.net
 Reported by:        frederic dot hardy at mageekbox dot net
 Summary:            filter_var return false for (float) $integer if
                     strlen($integer) > ini_get('prec
-Status:             Open
+Status:             Not a bug
 Type:               Bug
 Package:            Filter related
 Operating System:   Linux/OSX
 PHP Version:        5.6.3
-Assigned To:        
+Assigned To:        cmb
 Block user comment: N
 Private report:     N

 New Comment:

To clarify what Andrea already said:

<?php
ini_set('precision', 2);
echo (string) (float) 100;
?>

outputs as of PHP 8.0.0 (previously, the decimal separator was
locale dependent):

1.0E+2

Anyhow, 1.0E+2 is not a valid integer according to the
documentation of FILTER_VALIDATE_INT, and I have serious doubts
that we should change that behavior, even if we add a respective
flag, since in my opinion it makes no sense to pass a float to
filter_var() in the first place.

And anyway, this is not FILTER_VALIDATE_INT specific, but more a
general float to string conversion issue, see e.g. bug #66959.

I'm closing this as not a bug.  If anybody feels strongly that
this is a bug, or needs to be improved, please pursue the RFC
process[1].

[1] <https://wiki.php.net/rfc/howto>


Previous Comments:
------------------------------------------------------------------------
[2014-12-11 02:42:13] pajoye@php.net

Actually there are non sense inconsistencies here, due to the precision setting and conversion. Due
to this, some dots may be accepted and other not if the length of the string representation of the
value is bigger than the precision setting. This is a bug.

------------------------------------------------------------------------
[2014-12-10 14:05:11] frederic dot hardy at mageekbox dot net

Moreover, to be clear:

<?php

ini_set('precision', 2);
$i = 100;
var_dump(filter_var((float) $i, FILTER_VALIDATE_INT)); // bool(false)
var_dump((float) $i == $i); // bool(true)

?>

So, how a float can be equal to an integer if it's not an integer ?

------------------------------------------------------------------------
[2014-12-10 13:33:41] frederic dot hardy at mageekbox dot net

Pierre just say me on IRC to add this script to illustrate the problem:

<?php

ini_set('precision', 2);
var_dump(filter_var(1.0, FILTER_VALIDATE_INT)); // int(1)
var_dump(filter_var(100.0, FILTER_VALIDATE_INT)); // bool(false)

?>

So, filter_var(1.0, FILTER_VALIDATE_INT) should return false, as filter_var(100.0,
FILTER_VALIDATE_INT), or filter_var(100.0, FILTER_VALIDATE_INT) should return int(100)...

------------------------------------------------------------------------
[2014-12-05 18:58:18] frederic dot hardy at mageekbox dot net

So, filter_validate(1., FILTER_VALIDATE_INT) return (int) 1, but filter_validate(123456789123456.,
FILTER_VALIDATE_INT) return false, and it's not a bug. OK. All is right, we are in the PHP
world!

------------------------------------------------------------------------
[2014-12-05 14:44:38] ajf@php.net

(Though I agree it's pretty weird behaviour, FILTER_VALIDATE_INT could seriously be improved.
Still, it's not actually a bug.)

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=68551


--
Edit this bug report at https://bugs.php.net/bug.php?id=68551&edit=1


Thread (8 messages)

« previous php.bugs (#233100) next »