Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE
Edit report at https://bugs.php.net/bug.php?id=49510&edit=1
ID: 49510
Comment by: dernelson at corelogic 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:Filter related
Operating System: Linux
PHP Version:5.3.0
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
The question the developer is asking filter_var() is: "is boolean FALSE a valid
boolean", and the answer filter_var() is giving back is "nope." Regardless of
the technical details underlying the implementation, there is an obvious
problem here.
Short of changing PHP so that (string)FALSE === '0' (hah), I would suggest an
explicit test case for boolean FALSE values, so that the function can return
boolean FALSE in those cases, instead of NULL.
Previous Comments:
[2012-07-15 04:57:34] s...@php.net
Filters operate on strings. So any value that is passed to the filter_var()
will
be coerced into string. This means (boolean)false and '' is exactly the same
for
the filter. And that means the callbacks will be receiving strings too.
Now, the docs specifically say '' is a valid value for "boolean" filter and is
converted to false, so '' should not return NULL with FILTER_NULL_ON_FAILURE I
guess since it's documented not to be failure value.
[2012-06-24 00:34:38] 2072 at teaser dot fr
Knowing this issue I wanted to make a boolean validation filter of my own using
FILTER_CALLBACK but it suffers from the same problem, these filters are not
"boolean safe".
It appears that what is to be validated is first converted to a string.
So when given (bool)true my callback actually receives (string)'1' and
(string)'' when given (bool)false.
There is definitely something wrong.
(I'm using PHP 5.3.8)
[2010-09-01 13:55:06] schkovich at gmail dot com
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
[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.
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=49510
--
Edit this bug report at https://bugs.php.net/bug.php?id=49510&edit=1
Bug #50071 [Com]: Not honored: display_errors = stderr
Edit report at https://bugs.php.net/bug.php?id=50071&edit=1 ID: 50071 Comment by: dernelson at corelogic dot com Reported by:rank1seeker at gmail dot com Summary:Not honored: display_errors = stderr Status: Not a bug Type: Bug Package:*Configuration Issues Operating System: FreeBSD 7.2 PHP Version:5.3SVN-2009-11-03 (snap) Block user comment: N Private report: N New Comment: I can confirm that this is still an issue. I have the following setting: display_errors = stderr According to the php.ini documentation for this setting: ; Off = Do not display any errors ; stderr = Display errors to STDERR (affects only CGI/CLI binaries!) ; On or stdout = Display errors to STDOUT However, warnings are being dumped to the browser. I have also checked that the setting is correct in the .ini file reported in use by phpinfo(), and that no scripts are overriding this with ini_set(). Previous Comments: [2010-08-30 18:42:17] tedmasterweb at gmail dot com Sorry for that last post, I just realized that the "type" change in display_errors happened AFTER the version of PHP that I'm running. However, the suggestion to set error_reporting to 2147483647 (when setting it inside httpd.conf) causes display_errors to fail (to display all errors regardless of its actual setting). http://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting Wish it wasn't so, but alas, it is :-( [2010-08-30 18:32:33] tedmasterweb at gmail dot com I second the motion that display_errors=Off means off, completely off under all circumstances and regardless of reporting level. FWIW, I have the following in httpd.conf and I'm still seeing errors on the screen (PHP 5.3.1): php_value display_errors Off php_flag log_errors 1 php_value error_log /tmp/php_errors.log php_value error_reporting 2147483647 The value for error_reporting comes from the online documentation. The bottom line is I want to see ALL errors logged to a file, but none NONE on the screen. Maybe I've misunderstood something but it seems that I have my settings correct. [2010-04-10 18:06:39] ahollosi at xmp dot net This bug is NOT bogus. I can confirm it for PHP 5.3.2 on IIS 7.5 running on Windows Server 2008 R2 (I'm using the precompiled binaries from windows.php.net) display_errors=stderr is ignored, output goes to STDOUT, if log_errors=On and error_log is set to a file. And yes: I checked that the correct php.ini file is loaded. (On a side note: I don't think that bug #28349 is bogus either. If I set display_errors=Off I excpect it to mean "Off" and not "Well, mostly off, unless you set some other configuration options to wrong values.") [2009-11-04 13:50:12] rank1seeker at gmail dot com Of course it is loaded: I already use phpinfo() script Loaded Configuration File /usr/local/etc/php.ini I even tried: display_errors = stderr display_errors = Stderr display_errors = "stderr" display_errors = "Stderr" All behaves as: display_errors = On [2009-11-04 09:54:22] j...@php.net It works fine when your ini file is actually loaded. Check phpinfo() for "Loaded Configuration file" line.. 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=50071 -- Edit this bug report at https://bugs.php.net/bug.php?id=50071&edit=1
Bug #55138 [Com]: PDO_OCI cannot insert more than 1332 one byte chars in al32utf8 varchar2 field
Edit report at https://bugs.php.net/bug.php?id=55138&edit=1
ID: 55138
Comment by: dernelson at corelogic dot com
Reported by:an0nym at narod dot ru
Summary:PDO_OCI cannot insert more than 1332 one byte chars
in al32utf8 varchar2 field
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
This issue also affects PDOStatement::bindValue(), which does not have the 4th
parameter "length" like bindParam() does, so the workaround is not always
possible.
Previous Comments:
[2011-07-05 15:26:20] an0nym at narod dot ru
This issue can be worked around by adding $statement->bindParam(":test",
$test>>>, PDO::PARAM_STR, 4000<<<), however this does not fix the bug itself.
[2011-07-05 15:16:40] an0nym at narod dot ru
Description:
PDO_OCI cannot insert more than 1332 one byte chars in al32utf8 varchar2(4000
CHAR) field.
Additional info
$ php -v
PHP 5.3.6 (cli) (built: Apr 27 2011 23:46:11)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
$ uname -a
Linux ... 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64
x86_64 GNU/Linux
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
Test script:
---
PDO::ERRMODE_EXCEPTION));
foreach ($DB->query("SELECT value FROM nls_database_parameters WHERE parameter
= 'NLS_CHARACTERSET'") as $row)
echo $row["VALUE"], "\n";
$DB->exec("CREATE TABLE test(test VARCHAR2(4000 CHAR))");
$statement = $DB->prepare("INSERT INTO test VALUES(:test)");
$test = str_repeat(chr(97), 1332);
$statement->bindParam(":test", $test);
$statement->execute();
$test .= chr(97);
try {
$statement->execute();
} catch (PDOException $e) {
$DB->exec("DROP TABLE test");
exit("Error\n");
}
exit("Ok\n");
Expected result:
$ php test.php
AL32UTF8
Ok
Actual result:
--
$ php test.php
AL32UTF8
Error
--
Edit this bug report at https://bugs.php.net/bug.php?id=55138&edit=1
