Req #23158 [Com]: a new digit checker
Edit report at https://bugs.php.net/bug.php?id=23158&edit=1 ID: 23158 Comment by: lenar at city dot ee Reported by:melkor at dance dot student dot utwente dot nl Summary:a new digit checker Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: linux PHP Version:5CVS-2003-04-10 (dev) Block user comment: N Private report: N New Comment: ctype_digit() is actually partly bogus suggestion because of the behavior it has in the range -128 ... 255 if integer is passed. So ctype_digit(100) returns false. I can understand the reasoning in this case (replicate C API of ctype* functions) but it also means that is_digit() or similar is kind of warranted and would be a better fit for the dynamically typed world of PHP. Previous Comments: [2011-01-01 20:43:14] j...@php.net See above. [2007-12-31 22:49:29] michael at chunkycow dot com dot au This is bogus, ctype_digit(4500) returns true. [2003-04-10 17:31:15] melkor at dance dot student dot utwente dot nl For ID's in databases, a simple is_digit($mixed) check would be nice. is_numeric($mixed) also accepts 1.0E10 and such values, which are not valid for integer database IDs. ctype_digit($string) returns false for any integer it gets, because ctype_digit(4500) gets translated to isdigit(4500) which of course is not a valid ascii character at all. This might seem a little far fetched, but lots and lots of code uses is_numeric checks where they should not. I do this too, because otherwise I need 2 checks (is_integer($var) || ctype_digit($var)).. -- Edit this bug report at https://bugs.php.net/bug.php?id=23158&edit=1
Bug #55000 [Bgs]: instanceof should fail compile-time if checking for non existant class
Edit report at http://bugs.php.net/bug.php?id=55000&edit=1 ID: 55000 User updated by:lenar at city dot ee Reported by:lenar at city dot ee Summary:instanceof should fail compile-time if checking for non existant class Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Thank you for answering. But I think this is really a bug. Maybe it's different mindsets but I really think $a instanceof NonExistentClass should fail as would $a = new NonExistentClass() Sorry, I don't see the reasoning behind 'this is expected behavior'. The current behavior seems to be some evolutionary mishap at most, not something an average developer would expect from instanceof operator as it easily provides a way to shoot oneself in a leg (think simple typo). It's not really KISS. Previous Comments: [2011-06-07 20:33:22] d...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is expected behavior. You can do something like http://bugs.php.net/bug.php?id=55000&edit=1
[PHP-BUG] Bug #55000 [NEW]: instanceof should fail compile-time if checking for non existant class
From: Operating system: Linux PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Bug Bug description:instanceof should fail compile-time if checking for non existant class Description: If the use clause is missing (class/interface not found in current namespace) trigger some fatal error. This would catch many errors when the use clause is just forgotten by developer. I would understand the current behavior for those cases: 1) $a instanceof $b 2) $a instanceof 'BarClass' (not supported currently afaik) Test script: --- http://bugs.php.net/bug.php?id=55000&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55000&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55000&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55000&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55000&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55000&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55000&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55000&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55000&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55000&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55000&r=support Expected behavior: http://bugs.php.net/fix.php?id=55000&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55000&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55000&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55000&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55000&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55000&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55000&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55000&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55000&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55000&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55000&r=mysqlcfg
#30473 [Bgs->Opn]: in_array not working correctly
ID: 30473
User updated by: lenar at city dot ee
Reported By: lenar at city dot ee
-Status: Bogus
+Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: Feature/Change Request
Operating System: Debian
PHP Version: 4.3.9
New Comment:
Trying this as feature request to get review...
Previous Comments:
[2004-10-19 13:36:14] lenar at city dot ee
One more comment.
What I want to say is that comparisons in array functions should happen
like 'eq' operator does it in perl.
That would be intuitive. You can't change this, I presume, but that
would be the correct way IMHO.
[2004-10-19 11:56:05] lenar at city dot ee
I don't know then. All I'm sure the logic behind string and int
comparison isn't as one would expect from language doing automatic type
conversions.
You should cast (string) to (int) or (float) only if (string) is
numeric. Otherwise it's only logical to cast (int)/(float) operand to
string before comparing. That's how I would expect automatic type
conversion behave. Currently it's not intuitive.
("test" == 0) evaluating to true just doesn't seem right.
Just my $0.02 (which I do not have).
[2004-10-19 09:13:42] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2,
4.2.3, 4.3.5-4.3.9) and all do this:
[EMAIL PROTECTED]:/dat/dev/php/php-4.0.0$ ./php
X-Powered-By: PHP/4.0.0
Content-type: text/html
bool(true)
------------
[2004-10-18 18:46:24] lenar at city dot ee
Description:
function in_array() returns wrong result.
No way (string) "test" is equal to (int) 0.
It is not right to cast needle to the type of array value.
The same problem manifests itself with array_search().
You will say propably that you've added third parameter to in_array()
to take care of this, but in reality this isn't solution. The problem
is you can't blindly cast needle.
And manual says: If needle is a string, the comparison is done in a
case-sensitive manner.
Now tell me how you can compare a string you cast to (int) in
case-sensitive manner?
And this is all bad because I discovered this by accident after a
customer complained their stuff didn't work anymore.
That code used to work. I can swear. So you have broken BC it seems.
Reproduce code:
---
var_dump(in_array("test", array(0))
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=30473&edit=1
#30473 [Bgs]: in_array not working correctly
ID: 30473
User updated by: lenar at city dot ee
Reported By: lenar at city dot ee
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Debian
PHP Version: 4.3.9
New Comment:
One more comment.
What I want to say is that comparisons in array functions should happen
like 'eq' operator does it in perl.
That would be intuitive. You can't change this, I presume, but that
would be the correct way IMHO.
Previous Comments:
[2004-10-19 11:56:05] lenar at city dot ee
I don't know then. All I'm sure the logic behind string and int
comparison isn't as one would expect from language doing automatic type
conversions.
You should cast (string) to (int) or (float) only if (string) is
numeric. Otherwise it's only logical to cast (int)/(float) operand to
string before comparing. That's how I would expect automatic type
conversion behave. Currently it's not intuitive.
("test" == 0) evaluating to true just doesn't seem right.
Just my $0.02 (which I do not have).
[2004-10-19 09:13:42] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2,
4.2.3, 4.3.5-4.3.9) and all do this:
[EMAIL PROTECTED]:/dat/dev/php/php-4.0.0$ ./php
X-Powered-By: PHP/4.0.0
Content-type: text/html
bool(true)
------------
[2004-10-18 18:46:24] lenar at city dot ee
Description:
function in_array() returns wrong result.
No way (string) "test" is equal to (int) 0.
It is not right to cast needle to the type of array value.
The same problem manifests itself with array_search().
You will say propably that you've added third parameter to in_array()
to take care of this, but in reality this isn't solution. The problem
is you can't blindly cast needle.
And manual says: If needle is a string, the comparison is done in a
case-sensitive manner.
Now tell me how you can compare a string you cast to (int) in
case-sensitive manner?
And this is all bad because I discovered this by accident after a
customer complained their stuff didn't work anymore.
That code used to work. I can swear. So you have broken BC it seems.
Reproduce code:
---
var_dump(in_array("test", array(0))
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=30473&edit=1
#30473 [Bgs]: in_array not working correctly
ID: 30473
User updated by: lenar at city dot ee
Reported By: lenar at city dot ee
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Debian
PHP Version: 4.3.9
New Comment:
I don't know then. All I'm sure the logic behind string and int
comparison isn't as one would expect from language doing automatic type
conversions.
You should cast (string) to (int) or (float) only if (string) is
numeric. Otherwise it's only logical to cast (int)/(float) operand to
string before comparing. That's how I would expect automatic type
conversion behave. Currently it's not intuitive.
("test" == 0) evaluating to true just doesn't seem right.
Just my $0.02 (which I do not have).
Previous Comments:
[2004-10-19 09:13:42] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2,
4.2.3, 4.3.5-4.3.9) and all do this:
[EMAIL PROTECTED]:/dat/dev/php/php-4.0.0$ ./php
X-Powered-By: PHP/4.0.0
Content-type: text/html
bool(true)
----------------
[2004-10-18 18:46:24] lenar at city dot ee
Description:
function in_array() returns wrong result.
No way (string) "test" is equal to (int) 0.
It is not right to cast needle to the type of array value.
The same problem manifests itself with array_search().
You will say propably that you've added third parameter to in_array()
to take care of this, but in reality this isn't solution. The problem
is you can't blindly cast needle.
And manual says: If needle is a string, the comparison is done in a
case-sensitive manner.
Now tell me how you can compare a string you cast to (int) in
case-sensitive manner?
And this is all bad because I discovered this by accident after a
customer complained their stuff didn't work anymore.
That code used to work. I can swear. So you have broken BC it seems.
Reproduce code:
---
var_dump(in_array("test", array(0))
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=30473&edit=1
#30473 [NEW]: in_array not working correctly
From: lenar at city dot ee
Operating system: Debian
PHP version: 4.3.9
PHP Bug Type: Scripting Engine problem
Bug description: in_array not working correctly
Description:
function in_array() returns wrong result.
No way (string) "test" is equal to (int) 0.
It is not right to cast needle to the type of array value.
The same problem manifests itself with array_search().
You will say propably that you've added third parameter to in_array() to
take care of this, but in reality this isn't solution. The problem is you
can't blindly cast needle.
And manual says: If needle is a string, the comparison is done in a
case-sensitive manner.
Now tell me how you can compare a string you cast to (int) in
case-sensitive manner?
And this is all bad because I discovered this by accident after a customer
complained their stuff didn't work anymore.
That code used to work. I can swear. So you have broken BC it seems.
Reproduce code:
---
var_dump(in_array("test", array(0))
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit bug report at http://bugs.php.net/?id=30473&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30473&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30473&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30473&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30473&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30473&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30473&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30473&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30473&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30473&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30473&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30473&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30473&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30473&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30473&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30473&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30473&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30473&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30473&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30473&r=mysqlcfg
#24974 [Bgs->Dup]: random open_basedir errors
ID: 24974 User updated by: lenar at city dot ee Reported By: lenar at city dot ee -Status: Bogus +Status: Duplicate Bug Type: Apache related Operating System: debian/unstable PHP Version: 4.3.3RC2 New Comment: Sorry I missed somehow bug #24282. I really looked for similar bug reports before reporting. This seems same issue, yes. But even if #23580 is the same thing there is no way I could know this. It talks about include_path. Not open_basedir. Anyway I find your message somewhat disturbing. People make mistakes. Try to be more undestanding about dups. Simple notion about report being dupe of #xyz is enough. I just tried to ensure that 4.3.3 when released is free of this behavior. Is thinking like this wrong? Previous Comments: [2003-08-07 07:50:00] [EMAIL PROTECTED] And bug #24282 [2003-08-07 07:48:39] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. See bug #23580 [2003-08-07 07:14:26] lenar at city dot ee Description: The problem described in #19292 is still there. It's rare, but exists. Getting the error for virtualhosts that have no open_basedir defined. Seems open_basedir restriction form some other virtual host is in effect. Error message: open_basedir restriction in effect. File (/home/system/basesys.php) is not within the allowed path(s): (/tmp:/home/users/user1) in /home/system/modules/module.php) on line 26 it was said in #19292 setting open_basedir to none in every other virtualhost would help, but this is not a solution but a workaround. and in some cases a painful one. -- Edit this bug report at http://bugs.php.net/?id=24974&edit=1
#24974 [NEW]: #19292 happening again
From: lenar at city dot ee Operating system: debian/unstable PHP version: 4.3.3RC2 PHP Bug Type: Apache related Bug description: #19292 happening again Description: The problem described in #19292 is still there. It's rare, but exists. Getting the error for virtualhosts that have no open_basedir defined. Seems open_basedir restriction form some other virtual host is in effect. Error message: open_basedir restriction in effect. File (/home/system/basesys.php) is not within the allowed path(s): (/tmp:/home/users/user1) in /home/system/modules/module.php) on line 26 it was said in #19292 setting open_basedir to none in every other virtualhost would help, but this is not a solution but a workaround. and in some cases a painful one. -- Edit bug report at http://bugs.php.net/?id=24974&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24974&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24974&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24974&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24974&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24974&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24974&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24974&r=support Expected behavior: http://bugs.php.net/fix.php?id=24974&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24974&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24974&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24974&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24974&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24974&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24974&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24974&r=gnused
#24886 [Fbk->Opn]: PATH_TRANSLATED is wrong
ID: 24886 User updated by: lenar at city dot ee Reported By: lenar at city dot ee -Status: Feedback +Status: Open Bug Type: Apache related Operating System: debian/unstable PHP Version: 4.3.3RC2 New Comment: Really it's hard to explain this. One thing is for sure: echo $_SERVER['PATH_TRANSLATED'] and echo $PATH_TRANSLATED give different outputs. register_globals is _on_. Actually after studying it seems that $PATH_TRANSLATED gets the same value that is in $_ENV['PATH_TRANSLATED'] which in turn seems to be DOCUMENT_ROOT but sometimes it is not the correct DOCUMENT_ROOT but document root of some other virtual host. But anyway it should be easily testable to some degree with this code: I get: /var/www/ /home/user/public_html/index.php My variables_order = "EGPCS" So I would expect the value in $_SERVER to be accessible by $PATH_TRANSLATED not the one in $_ENV. Why the value in $_ENV sometimes contains the path of some other virtul host's document root is still beyond me. Apache is 1.3.27 Previous Comments: [2003-07-31 13:23:05] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. ---------------- [2003-07-31 11:05:31] lenar at city dot ee Description: in apache configuration where many virtual hosts are in use, PATH_TRANSLATED doesn't always get set to correct path. Instead the value seems to reflect some other (older) request. Possibly the value is correct only if brand new apache child serves the request. The value in $_SERVER array is always correct. Current workaround: add extract($_SERVER, EXTR_OVERWRITE); to your auto-prepend php file. -- Edit this bug report at http://bugs.php.net/?id=24886&edit=1
#24886 [NEW]: PATH_TRANSLATED is wrong
From: lenar at city dot ee Operating system: debian/unstable PHP version: 4.3.3RC2 PHP Bug Type: Apache related Bug description: PATH_TRANSLATED is wrong Description: in apache configuration where many virtual hosts are in use, PATH_TRANSLATED doesn't always get set to correct path. Instead the value seems to reflect some other (older) request. Possibly the value is correct only if brand new apache child serves the request. The value in $_SERVER array is always correct. Current workaround: add extract($_SERVER, EXTR_OVERWRITE); to your auto-prepend php file. -- Edit bug report at http://bugs.php.net/?id=24886&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24886&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24886&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24886&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24886&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24886&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24886&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24886&r=support Expected behavior: http://bugs.php.net/fix.php?id=24886&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24886&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24886&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24886&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24886&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24886&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24886&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24886&r=gnused
