From: [EMAIL PROTECTED]
Operating system: RedHat 7.2
PHP version: 4CVS-2002-11-22 (stable)
PHP Bug Type: Variables related
Bug description: Variable values inconsistent with assignment statements.
I haven't been able to recreate this problem at all in a controlled
environment, but I can recreate it consistently where we originally
discovered it.
Here is the snidbit of the function causing the erroneous output:
_______________________________________________________
function do_mail_command($cmd,$server="morpheus.myersinternet.com") {
print "values prior to setting are:<p> server => $server<br>errno =>
$errno<br>errstr => $errstr<br>whoknows => $whoknows<br>";
if(empty($server)) {
print "<br>server is empty, so changing values<p>";
$server = "this is the first one";
$errno = "here is the second one";
$errstr = "but they will all be this";
$random_variable = "does this work";
print "values after setting:<p> server => $server<br>errno =>
$errno<br>errstr => $errstr<br>whoknows => $whoknows";
}
$fp = fsockopen($server, 5154, $errno, $errstr, 10);
_________________________________________________________
Here is the output of that exact piece of code:
values prior to setting are:
server => morpheus.myersinternet.com
errno => morpheus.myersinternet.com
errstr => morpheus.myersinternet.com
whoknows => morpheus.myersinternet.com
server is empty, so changing values
values after setting:
server => does this work
errno => does this work
errstr => does this work
whoknows => does this work
____________________________________________________
There are three main problems I see occurring here.
1. The first print statement prints out a bunch of "random" variables,
$server being the only that has previously been given a value. However, as
the print statement shows, they ALL have values.
2. The empty($server) check returns true even though its obviously clear
that $server is NOT empty.
3. After performing variuos assignment statements within the if block, and
printing out the variable values, it's clear that ALL the variables
receive the value of the LAST assignment statement made.
We found this bug because when calling fsockopen, the $errno and $errstr
variables had values even though they were never assigned any values and
it was causing the function to fail when trying to open the socket. This
function was working fine prior to our upgrade to the latest version.
Our configure line is:
LoadModule php4_module modules/libphp4.so
We are also heavily using session variables in case that helps to recreate
the bug.
Thanks
--
Edit bug report at http://bugs.php.net/?id=20583&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20583&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20583&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20583&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20583&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20583&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=20583&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20583&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=20583&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=20583&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20583&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20583&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20583&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20583&r=isapi
