Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE

2010-09-01 Thread schkovich at gmail dot com
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

2011-04-02 Thread schkovich at gmail dot com
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

2011-04-05 Thread schkovich at gmail dot com
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