[PHP-DOC] #26821 [Com]: if(NANC 0) - always evaluates TRUE
ID: 26821
Comment by: skissane at ics dot mq dot edu dot au
Reported By: ivo at benetech dot org
Status: Open
Bug Type: Documentation problem
Operating System: Linux / RH 7.3
PHP Version: 4.3.4
New Comment:
Vrana: your comment makes no sense. If NANC is converted to 0, then 0
0 would be FALSE, not true.
Compare these expressions:
NANC 0result TRUE
NANC 0 result FALSE
0 0 result FALSE
So it seems it is neither converting NANC to an integer 0, nor 0 to a
string 0. What actually is going on? The documentation should clarify
this.
Previous Comments:
[2004-01-07 13:20:58] ivo at benetech dot org
It also print 0 as expected.
if( (int) NANC 0)
also evaluates as expected.
[2004-01-07 05:53:18] [EMAIL PROTECTED]
NANC is converted to 0 for comparison. It works for me as expected.
What is printed by the code ?php echo intval(NANC); ? on your
system?
[2004-01-06 18:08:12] ivo at benetech dot org
Documentation needs to be more explicit about php being strongly
typed.
http://www.php.net/manual/en/language.types.type-juggling.php
or
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
[2004-01-06 17:23:58] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/types.comparisons.php
(never ever compare different types like that)
[2004-01-06 16:28:47] ivo at benetech dot org
Description:
The statement...
if(NANC 0)
...always evaluates TRUE.
Reproduce code:
---
if(NANC 0)
{
print(should not happen...but does\n);
}
else
{
print(should happen...but doesnt\n);
}
Expected result:
echoed to the console:
should happen...but doesnt
Actual result:
--
echoed to the console:
should not happen...but does
--
Edit this bug report at http://bugs.php.net/?id=26821edit=1
[PHP-DOC] #26429 [NEW]: Documentation for $_SERVER[SCRIPT_FILENAME] incorrect
From: skissane at ics dot mq dot edu dot au Operating system: Linux PHP version: 4.3.4 PHP Bug Type: Documentation problem Bug description: Documentation for $_SERVER[SCRIPT_FILENAME] incorrect Description: According to the documentation: 'SCRIPT_FILENAME' The absolute pathname of the currently executing script. But, when I do 'echo $_SERVER[SCRIPT_FILENAME]', using PHP-CLI, I get a pathname relative to the current directory. So either the docs are wrong, or the code is buggy (suggest that documented behaviour is more useful than actual behaviour, hence code should be changed.) (Despite what the form forced me to say above, I'm actually using 4.3.4RC1, not 4.3.4, but I hope it makes no difference. Apologies if it does.) Reproduce code: --- Make a directory called foo, under $HOME. Put this file as test.php in $HOME: ? echo $_SERVER[SCRIPT_FILENAME] . \n; Now cd to $HOME Execute: php foo/test.php Expected result: path to your home directory/foo/test.php Actual result: -- foo/test.php -- Edit bug report at http://bugs.php.net/?id=26429edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26429r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26429r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26429r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26429r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26429r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26429r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26429r=support Expected behavior: http://bugs.php.net/fix.php?id=26429r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26429r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26429r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26429r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26429r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26429r=dst IIS Stability: http://bugs.php.net/fix.php?id=26429r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26429r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26429r=float
[PHP-DOC] #26429 [Opn]: Documentation for $_SERVER[SCRIPT_FILENAME] incorrect
ID: 26429 User updated by: skissane at ics dot mq dot edu dot au Reported By: skissane at ics dot mq dot edu dot au Status: Open Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.4 New Comment: rasmus wrote: The docs should be modified to reflect the fact that all server variables except PHP_SELF, argc and argv are set by the web server and PHP has absolutely no control over their values Not true -- As I said, I am using PHP-CLI. No webserver involved at all. Of course PHP has control over them all when running using the CLI sapi (excluding of course any brought in from the environment...) Previous Comments: [2003-11-26 23:55:14] [EMAIL PROTECTED] The docs should be modified to reflect the fact that all server variables except PHP_SELF, argc and argv are set by the web server and PHP has absolutely no control over their values. While Apache sets them to one thing, another server may set them to another, and there may be differences between the server module version and the CGI interface to any of these web servers. [2003-11-26 23:50:28] skissane at ics dot mq dot edu dot au Description: According to the documentation: 'SCRIPT_FILENAME' The absolute pathname of the currently executing script. But, when I do 'echo $_SERVER[SCRIPT_FILENAME]', using PHP-CLI, I get a pathname relative to the current directory. So either the docs are wrong, or the code is buggy (suggest that documented behaviour is more useful than actual behaviour, hence code should be changed.) (Despite what the form forced me to say above, I'm actually using 4.3.4RC1, not 4.3.4, but I hope it makes no difference. Apologies if it does.) Reproduce code: --- Make a directory called foo, under $HOME. Put this file as test.php in $HOME: ? echo $_SERVER[SCRIPT_FILENAME] . \n; Now cd to $HOME Execute: php foo/test.php Expected result: path to your home directory/foo/test.php Actual result: -- foo/test.php -- Edit this bug report at http://bugs.php.net/?id=26429edit=1
