http://pear.php.net/bugs/search.php?cmd=display&package_name%5B0%5D=Validate Search Results en-us pear-webmaster@lists.php.net pear-webmaster@lists.php.net hourly 1 2000-01-01T12:00+00:00 http://pear.php.net/gifs/pearsmall.gif http://pear.php.net/bugs http://pear.php.net/bugs/29034 Validate Bug Reported by neufeind 2025-04-18T17:35:00+00:00 PHP: 8.0.0 (Specify exact version in description) OS: Package Version: 0.8.6 Description: ------------ PHP 8.4.x (although that doesn't really matter; code is unclean) Inside Validate.php there is a static call to _modf(). That function needs to be declared "static". error says: called statically in /usr/share/pear/Validate.php:1004 Stack trace: #0 /usr/share/pear/Validate.php(1033)]]> Validate Bug Reported by neufeind 2025-04-18T17:35:00+00:00 PHP: 8.0.0 (Specify exact version in description) OS: Package Version: 0.8.6 Description: ------------ PHP 8.4.x (although that doesn't really matter; code is unclean) Inside Validate.php there is a static call to _modf(). That function needs to be declared "static". error says: called statically in /usr/share/pear/Validate.php:1004 Stack trace: #0 /usr/share/pear/Validate.php(1033)]]> 2025-04-18T17:35:00+00:00 pear &#x64;&#111;&#x74; neufeind &#x61;&#116; speedpartner &#x64;&#111;&#x74; de Validate Bug http://pear.php.net/bugs/19630 Validate Bug Reported by helen_griffiths 2012-10-03T17:58:46+00:00 PHP: 5.4.6 OS: Linux Fedora 3.5.3-1.fc17.x86_64 Package Version: 0.8.5 Description: ------------ Validate::string used with max_length=>0 in the options array ought to return false when a string is longer than 0 characters, but actually returns true. Test script: --------------- $tucaspn = "0001234567" ; $tsha1 = "8216f35ab34f4e3910fd384565636f57dd7f50a2" ; $tpepper = "kittens0ft" ; $tchars = VALIDATE_NUM ; $tmin = 0 ; $tmax = 0 ; function ucasPnCheckerF($ucaspn,$pepper,$sha1,$min,$max,$chars) { // returns true or false return (Validate::string($ucaspn, array("min_length"=>$min, "max_length"=>$max, "format"=>$chars)) && sha1PepperChecker($ucaspn, $pepper, $sha1)) ; } if (ucasPnCheckerF($tucaspn,$tpepper,$tsha1,$tmin,$tmax,$tchars)) { echo "This should have failed but didn't.<br />" ; } else echo "I'll eat my hat." ; function ucasPnCheckerT($ucaspn,$pepper,$sha1,$min,$max,$chars) { // returns true or false return ((0 < $max) && Validate::string($ucaspn, array("min_length"=>$min, "max_length"=>$max, "format"=>$chars)) && sha1PepperChecker($ucaspn, $pepper, $sha1)) ; } if (ucasPnCheckerT($tucaspn,$tpepper,$tsha1,$tmin,$tmax,$tchars)) { echo "This should have failed.<br />" ; } else echo "Workaround for bug." ; Expected result: ---------------- I'll eat my hat. Workaround for bug. Actual result: -------------- This should have failed but didn't. Workaround for bug.]]> Validate Bug Reported by helen_griffiths 2012-10-03T17:58:46+00:00 PHP: 5.4.6 OS: Linux Fedora 3.5.3-1.fc17.x86_64 Package Version: 0.8.5 Description: ------------ Validate::string used with max_length=>0 in the options array ought to return false when a string is longer than 0 characters, but actually returns true. Test script: --------------- $tucaspn = "0001234567" ; $tsha1 = "8216f35ab34f4e3910fd384565636f57dd7f50a2" ; $tpepper = "kittens0ft" ; $tchars = VALIDATE_NUM ; $tmin = 0 ; $tmax = 0 ; function ucasPnCheckerF($ucaspn,$pepper,$sha1,$min,$max,$chars) { // returns true or false return (Validate::string($ucaspn, array("min_length"=>$min, "max_length"=>$max, "format"=>$chars)) && sha1PepperChecker($ucaspn, $pepper, $sha1)) ; } if (ucasPnCheckerF($tucaspn,$tpepper,$tsha1,$tmin,$tmax,$tchars)) { echo "This should have failed but didn't.<br />" ; } else echo "I'll eat my hat." ; function ucasPnCheckerT($ucaspn,$pepper,$sha1,$min,$max,$chars) { // returns true or false return ((0 < $max) && Validate::string($ucaspn, array("min_length"=>$min, "max_length"=>$max, "format"=>$chars)) && sha1PepperChecker($ucaspn, $pepper, $sha1)) ; } if (ucasPnCheckerT($tucaspn,$tpepper,$tsha1,$tmin,$tmax,$tchars)) { echo "This should have failed.<br />" ; } else echo "Workaround for bug." ; Expected result: ---------------- I'll eat my hat. Workaround for bug. Actual result: -------------- This should have failed but didn't. Workaround for bug.]]> 2012-10-03T18:32:44+00:00 helen &#x61;&#116; helengriffiths &#x64;&#111;&#x74; me &#x64;&#111;&#x74; uk Validate Bug http://pear.php.net/bugs/19132 Validate Bug Reported by tkorkunckaya 2011-12-13T05:08:09+00:00 PHP: 5.3.6 OS: Debian GNU/Linux Package Version: 0.8.4 Description: ------------ define('VALIDATE_EALPHA_LOWER', VALIDATE_ALPHA_LOWER . 'áéíóúýàèìòùäëïöüÿâêîôûãñõ¨åæç½ðøþß'); define('VALIDATE_EALPHA_UPPER', VALIDATE_ALPHA_UPPER . 'ÁÉÍÓÚÝÀÈÌÒÙÄËÏÖܾÂÊÎÔÛÃÑÕ¦ÅÆǼÐØÞ'); accented Turkish chars (???,???) are wrong: (Ð,?,Þ,ð,?,þ) Test script: --------------- if (Validate::string("A?RI ?EHR?", array( 'format' => VALIDATE_SPACE . VALIDATE_EALPHA_UPPER))) { echo 'Valid!'; } else { echo 'Invalid!'; } returns Invalid! Expected result: ---------------- must return Valid! Actual result: -------------- define('VALIDATE_EALPHA_LOWER', VALIDATE_ALPHA_LOWER . 'áéíóúýàèìòùäëïöüÿâêîôûãñõ¨åæç½øß???'); define('VALIDATE_EALPHA_UPPER', VALIDATE_ALPHA_UPPER . 'ÁÉÍÓÚÝÀÈÌÒÙÄËÏÖܾÂÊÎÔÛÃÑÕ¦ÅÆǼØ???'); if you define VALIDATE_EALPHA_UPPER as stated above it validates correctly.]]> Validate Bug Reported by tkorkunckaya 2011-12-13T05:08:09+00:00 PHP: 5.3.6 OS: Debian GNU/Linux Package Version: 0.8.4 Description: ------------ define('VALIDATE_EALPHA_LOWER', VALIDATE_ALPHA_LOWER . 'áéíóúýàèìòùäëïöüÿâêîôûãñõ¨åæç½ðøþß'); define('VALIDATE_EALPHA_UPPER', VALIDATE_ALPHA_UPPER . 'ÁÉÍÓÚÝÀÈÌÒÙÄËÏÖܾÂÊÎÔÛÃÑÕ¦ÅÆǼÐØÞ'); accented Turkish chars (???,???) are wrong: (Ð,?,Þ,ð,?,þ) Test script: --------------- if (Validate::string("A?RI ?EHR?", array( 'format' => VALIDATE_SPACE . VALIDATE_EALPHA_UPPER))) { echo 'Valid!'; } else { echo 'Invalid!'; } returns Invalid! Expected result: ---------------- must return Valid! Actual result: -------------- define('VALIDATE_EALPHA_LOWER', VALIDATE_ALPHA_LOWER . 'áéíóúýàèìòùäëïöüÿâêîôûãñõ¨åæç½øß???'); define('VALIDATE_EALPHA_UPPER', VALIDATE_ALPHA_UPPER . 'ÁÉÍÓÚÝÀÈÌÒÙÄËÏÖܾÂÊÎÔÛÃÑÕ¦ÅÆǼØ???'); if you define VALIDATE_EALPHA_UPPER as stated above it validates correctly.]]> 2011-12-13T17:08:05+00:00 tolga &#x61;&#116; profelis &#x64;&#111;&#x74; com &#x64;&#111;&#x74; tr Validate Bug http://pear.php.net/bugs/17975 Validate Bug Reported by jdolecek 2010-10-19T19:04:25+00:00 PHP: 5.3.3 OS: MacOS Package Version: 0.8.4 Description: ------------ Package is not compatible with running under E_STRICT - methods are not marked as static, so one gets warning when calling e.g. Validate::uri() from other code (such as Services_Facebook). It would be cool to mark all functions as static and private/public as appropriate, to make it possible to run Validate with E_STRICT.]]> Validate Bug Reported by jdolecek 2010-10-19T19:04:25+00:00 PHP: 5.3.3 OS: MacOS Package Version: 0.8.4 Description: ------------ Package is not compatible with running under E_STRICT - methods are not marked as static, so one gets warning when calling e.g. Validate::uri() from other code (such as Services_Facebook). It would be cool to mark all functions as static and private/public as appropriate, to make it possible to run Validate with E_STRICT.]]> 2010-10-20T16:31:57+00:00 jaromir &#x64;&#111;&#x74; dolecek &#x61;&#116; skype &#x64;&#111;&#x74; net Validate Bug http://pear.php.net/bugs/17043 Validate Bug Reported by alan_k 2010-01-29T09:31:31+00:00 PHP: Irrelevant OS: Linux Package Version: 0.8.3 Description: ------------ I could not think of a better way to hide the warnings, but this fixes the code in there. function _includePathFileExists($filename) { $paths = explode(":", ini_get("include_path")); $bd = explode(":", ini_get('open_basedir')); $result = false; foreach($paths as $val) { // silenced due to open_basedir $result = @file_exists($val . "/" . $filename); if ($result) { return true; } } return false; } }]]> Validate Bug Reported by alan_k 2010-01-29T09:31:31+00:00 PHP: Irrelevant OS: Linux Package Version: 0.8.3 Description: ------------ I could not think of a better way to hide the warnings, but this fixes the code in there. function _includePathFileExists($filename) { $paths = explode(":", ini_get("include_path")); $bd = explode(":", ini_get('open_basedir')); $result = false; foreach($paths as $val) { // silenced due to open_basedir $result = @file_exists($val . "/" . $filename); if ($result) { return true; } } return false; } }]]> 2010-01-29T09:31:59+00:00 alan &#x61;&#116; akbkhome &#x64;&#111;&#x74; com Validate Bug http://pear.php.net/bugs/16897 Validate Bug Reported by davidsimpson 2009-12-10T16:28:08+00:00 PHP: 5.2.5 OS: Windows and Solaris Package Version: 0.8.3 Description: ------------ Validation of decimal numbers such as ".5" fails, although "0.5" passes. As db engines (in our case Oracle) do not store the leading zero, we get validation failures using DB_DataObject in combination with Validate. Test script: --------------- $testval='-.5'; $test = Validate::number( $testval, array('decimal'=>'.')); var_dump($test); Replacing line 270 of Validate.php with the following two lines gives the expected result: $num_regex = $dec_regex == '' ? "|^[-+]?\s*[0-9]+\$|" : "/^[-+]?\s*(([0-9]+)([$decimal][0-9]+)?)|([$decimal][0-9]+)\$/"; if (!preg_match($num_regex, $number)) { Expected result: ---------------- bool(true) Actual result: -------------- bool(false)]]> Validate Bug Reported by davidsimpson 2009-12-10T16:28:08+00:00 PHP: 5.2.5 OS: Windows and Solaris Package Version: 0.8.3 Description: ------------ Validation of decimal numbers such as ".5" fails, although "0.5" passes. As db engines (in our case Oracle) do not store the leading zero, we get validation failures using DB_DataObject in combination with Validate. Test script: --------------- $testval='-.5'; $test = Validate::number( $testval, array('decimal'=>'.')); var_dump($test); Replacing line 270 of Validate.php with the following two lines gives the expected result: $num_regex = $dec_regex == '' ? "|^[-+]?\s*[0-9]+\$|" : "/^[-+]?\s*(([0-9]+)([$decimal][0-9]+)?)|([$decimal][0-9]+)\$/"; if (!preg_match($num_regex, $number)) { Expected result: ---------------- bool(true) Actual result: -------------- bool(false)]]> 2009-12-10T16:28:08+00:00 david &#x64;&#111;&#x74; simpson &#x61;&#116; tronsystems &#x64;&#111;&#x74; co &#x64;&#111;&#x74; uk Validate Bug http://pear.php.net/bugs/13825 Validate Bug Reported by ctj951 2008-05-02T21:00:52+00:00 PHP: 5.2.5 OS: Mac OS X Package Version: 0.8.1 Description: ------------ The email validation in the Validate PEAR package doesn't work correctly. This is because the '&' symbol though valid in emails such as: "Joe & Mac"@example.com isn't accepted by the email parser. This is caused by the simple fact that the __stringToUtf7() routine doesn't recognize any string with a '&' sign as valid UTF7. This is despite the fact that the '&' character is valid UTF7 as defined by RFC 2152 as I read it: http://www.faqs.org/rfcs/rfc2152.html In the __stringToUtf7() routine the following substitution is made for the '&' character: elseif ($char == '&') { $return .= '&-'; } Thus when the UTF7 "return" string is returned it doesn't match the original string passed to the UTF7 routine and all '&' characters are replaced by '&-'. Its not clear why this substitution is made at all. Especially since this routine is only used from within the email parser. In any case the result is that the following test in __emailRFC822() fails with emails like "Joe & Mac"@example.com: if (Validate::__stringToUtf7($email) != $email) { return false; } Leading to the email parser returning that emails like "Joe & Mac"@example.com are invalid email addresses when in fact they are valid. Test script: --------------- Script 1: (fails when should succeed) $Email = '"Joe & Mac"@example.com'; $Options = 0; assert( Validate::__emailRFC822( $Email, $Options ) ); Script 2: (fails when should succeed) $string = '&'; assert( __stringToUtf7($string) == $string ); Expected result: ---------------- Scripts fail when they should succeed Actual result: -------------- Scripts faile.]]> Validate Bug Reported by ctj951 2008-05-02T21:00:52+00:00 PHP: 5.2.5 OS: Mac OS X Package Version: 0.8.1 Description: ------------ The email validation in the Validate PEAR package doesn't work correctly. This is because the '&' symbol though valid in emails such as: "Joe & Mac"@example.com isn't accepted by the email parser. This is caused by the simple fact that the __stringToUtf7() routine doesn't recognize any string with a '&' sign as valid UTF7. This is despite the fact that the '&' character is valid UTF7 as defined by RFC 2152 as I read it: http://www.faqs.org/rfcs/rfc2152.html In the __stringToUtf7() routine the following substitution is made for the '&' character: elseif ($char == '&') { $return .= '&-'; } Thus when the UTF7 "return" string is returned it doesn't match the original string passed to the UTF7 routine and all '&' characters are replaced by '&-'. Its not clear why this substitution is made at all. Especially since this routine is only used from within the email parser. In any case the result is that the following test in __emailRFC822() fails with emails like "Joe & Mac"@example.com: if (Validate::__stringToUtf7($email) != $email) { return false; } Leading to the email parser returning that emails like "Joe & Mac"@example.com are invalid email addresses when in fact they are valid. Test script: --------------- Script 1: (fails when should succeed) $Email = '"Joe & Mac"@example.com'; $Options = 0; assert( Validate::__emailRFC822( $Email, $Options ) ); Script 2: (fails when should succeed) $string = '&'; assert( __stringToUtf7($string) == $string ); Expected result: ---------------- Scripts fail when they should succeed Actual result: -------------- Scripts faile.]]> 2008-06-21T06:05:07+00:00 chadsspameateremail &#x61;&#116; yahoo &#x64;&#111;&#x74; com Validate Bug