Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE
Edit report at http://bugs.php.net/bug.php?id=49510&edit=1 ID: 49510 Comment by: schkovich at gmail dot com Reported by:m dot kurzyna at crystalpoint dot pl Summary:boolean validation fails with FILTER_NULL_ON_FAILURE Status: Assigned Type: Feature/Change Request Package:Feature/Change Request Operating System: Linux PHP Version:5.3.0 Assigned To:pajoye Block user comment: N New Comment: filter_var(false,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) // got NULL, expected false That does not make sense at all! Further on, I have to agree with m.kurzyna that since false === (bool)"" filter_var("",FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) should return FALSE and not NULL. Basically, as implemented, getting FALSE from filter_var(false,FILTER_VALIDATE_BOOLEAN) means that validation failed. It appears to be a design problem since filter_var() as specified will return FALSE if the filter fails making it impossible to distinguish if filter failed or valid FALSE value is returned. Therefore, instead returning FALSE if filter fails perhaps warning could be issued or even better exception thrown. On addition when voting I've wrongly selected that I am not using the same version and the same operating system. Correct ones are: PHP Version => 5.3.2-1ubuntu4.2 System => Linux schkovich 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64 Previous Comments: [2009-09-10 11:24:37] m dot kurzyna at crystalpoint dot pl As much as i'd like to have empty string be invalid false cast i have to disagree with you for consistency reasons. If (boolean)'' == false then filter_var('','boolean') should also return false. Both in general and in case of FILTER_NULL_ON_FAILURE (just like the documentation states). Also, because i can't stress it enough, this is a VALIDATOR not a SANITIZER so using it as a strict caster is secondary to it's validation purpose and as such it currently fails both on implied and explicit behavior. The ideal solution would be to have FILTER_VALIDATE_BOOLEAN roughly equal to current behavior with FILTER_NULL_ON_FAILURE and a *seperate* FILTER_SANITIZE_BOOLEAN similar to current behavior w/o the null failure flag. This however probably is impossible due to BC. [2009-09-10 11:09:43] sjo...@php.net I agree that filter_var() should return null for the empty string. I think that this usage of filter_var() is meant to convert string representations of booleans to boolean values. That is, "true", "on", "1", "false", "off" and "0" should be converted, other strings should return null. [2009-09-10 09:05:53] m dot kurzyna at crystalpoint dot pl Personally i think it's just fine (empty string ain't false - if anything it's null) but in PHP world it is (both on PHP and C levels): (string)false = '' (boolean)'' == false Z_STRLEN_P(value) = 0 Oh, and there is this little documentation thingy you like to cite from time to time: If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for "0", "false", "off", "no", and "", and NULL is returned for all non-boolean values. where empty string is explicitly stated as being false. [2009-09-10 08:57:29] sjo...@php.net Why do you think it is wrong that it returns null for an empty string? [2009-09-10 08:53:11] m dot kurzyna at crystalpoint dot pl Actually it is broken even more then i initially reported because it also returns NULL for empty string: filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)) // got NULL, expected false The problem is in ext/filter/logical_filters.c(233) - the check is done by using string representation of zval being checked. For false value it's an empty string and the switch from line 244 doesn't cover this case (hence same result for false and empty string). Something along the lines of following patch should fix the problem: --- logical_filters.c 2009-06-10 21:01:17.0 +0200 +++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200 @@ -242,6 +242,10 @@ * returns false for "0", "false", "off", "no", and "" * null otherwise. */ switch
[PHP-BUG] Bug #54451 [NEW]: Cannot Compile PDO_OCI on Ubuntu
From: Operating system: Linux Ubuntu PHP version: 5.3SVN-2011-04-02 (snap) Package: PDO related Bug Type: Bug Bug description:Cannot Compile PDO_OCI on Ubuntu Description: PDO_OCI complied using PHP 5.3-201103302030 snap Oracle Instant Client 11.2.0.2.0 x64 zip Basic, SDK Running: PHP 5.3.3-1ubuntu9.3, on Linux 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 Configure reports two problems: * PHP_CHECK_PDO_INCLUDES variable must and with _cv_ to be cached * cannot find php_pdo_driver.h Test script: --- user@user:/usr/local/src/pdo_oci$ phpize Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 ... config.m4:202: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached ... aclocal.m4:2739: PHP_CHECK_PDO_INCLUDES is expanded from... config.m4:202: the top level user@user:/usr/local/src/pdo_oci$ ./configure --with-pdo-oci=shared,instantclient,/opt/oracle/instantclient,11.2 checking for grep that handles long lines and -e... /bin/grep ... checking for PDO includes... checking for PDO includes... configure: error: Cannot find php_pdo_driver.h. Expected result: Configure runs successfully Actual result: -- Configure fails with message: Cannot find php_pdo_driver.h -- Edit bug report at http://bugs.php.net/bug.php?id=54451&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54451&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54451&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54451&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54451&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54451&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54451&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54451&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54451&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54451&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54451&r=support Expected behavior: http://bugs.php.net/fix.php?id=54451&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54451&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54451&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54451&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54451&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54451&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54451&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54451&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54451&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54451&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54451&r=mysqlcfg
Bug #54451 [Com]: Cannot Compile PDO_* on Ubuntu
Edit report at http://bugs.php.net/bug.php?id=54451&edit=1 ID: 54451 Comment by: schkovich at gmail dot com Reported by:schkovich at gmail dot com Summary:Cannot Compile PDO_* on Ubuntu Status: Open Type: Bug Package:PDO related Operating System: Linux Ubuntu PHP Version:5.3SVN-2011-04-02 (snap) Block user comment: N Private report: N New Comment: Right. I scanned other extensions to see how similar cases are handled. Closest match is in XMLRPC extension. See ext/xmlrpc/config.m4 lines 95 - 116. Here is the new patch having loop: http://ubuntuone.com/p/kyx/ I guess that setting pdo_inc_path could be further optimized to eliminate the first condition at least. Speaking of: if test -f $abs_srcdir/include/php/ext/pdo/php_pdo_driver.h; then pdo_inc_path=$abs_srcdir/ext appears to be wrong. Shouldn't the second line (line 208) read pdo_inc_path=$abs_srcdir/include/php/ext? Previous Comments: [2011-04-04 19:14:51] s...@php.net This is generic across PDP. All ext/pdo_*/config.m4 files make the same assumptions about the install path. [2011-04-02 12:03:08] schkovich at gmail dot com Description: PDO_OCI complied using PHP 5.3-201103302030 snap Oracle Instant Client 11.2.0.2.0 x64 zip Basic, SDK Running: PHP 5.3.3-1ubuntu9.3, on Linux 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 Configure reports two problems: * PHP_CHECK_PDO_INCLUDES variable must and with _cv_ to be cached * cannot find php_pdo_driver.h Test script: --- user@user:/usr/local/src/pdo_oci$ phpize Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 ... config.m4:202: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached ... aclocal.m4:2739: PHP_CHECK_PDO_INCLUDES is expanded from... config.m4:202: the top level user@user:/usr/local/src/pdo_oci$ ./configure --with-pdo-oci=shared,instantclient,/opt/oracle/instantclient,11.2 checking for grep that handles long lines and -e... /bin/grep ... checking for PDO includes... checking for PDO includes... configure: error: Cannot find php_pdo_driver.h. Expected result: Configure runs successfully Actual result: -- Configure fails with message: Cannot find php_pdo_driver.h -- Edit this bug report at http://bugs.php.net/bug.php?id=54451&edit=1