Strange Bug in IsSetValue()

Hi,

some little reangement to the function let it run as expected. see the diff from forms.php

2275,2276c2275,2281
<
< return(($file ? (IsSet($_FILES[$variable]) || IsSet($HTTP_POST_FILES[$variable])) : (IsSet($_GET[$variable]) || IsSet($HTTP_GET_VARS[$variable]) || IsSet($_POST[$variable]) || IsSet($HTTP_POST_VARS[$variable]))) || IsSet($GLOBALS[$variable]));
---
> if($file){
> $isSetVal = (IsSet($_FILES[$variable]) || IsSet($HTTP_POST_FILES[$variable]));
> } else {
> $isSetVal = (IsSet($_GET[$variable]) || IsSet($HTTP_GET_VARS[$variable]) || IsSet($_POST[$variable]) || IsSet($HTTP_POST_VARS[$variable]));
> }
> $isSetVal |= IsSet($GLOBALS[$variable]);
> return($isSetVal);

I am not sure what problems your patch solves. Can you give an example?

hi,

its not so easy to describe.

Have a bigger application wich use your fine class. in one special occassion it was unable to submit the form, "doit" was true. while debuging i noticed the IsSetValule() which is checking the doit var, is returning unknown. in the function itself its set to NULL.

My code does exactly the same as yours, in fact its the same code split up in more lines. But with the splitup it returns the correct value. Very strange.

The really strange thing... on the live system the orginal code works, on the develop system not. Same PHP Version, same php.ini config, same modules. Same CPU, same compiler flags.

Sorry i can give you code to reproduce it, there are so many classes which interact with each other.

I thought maybe you or another user of your class may have a similiar problem one day, and the split up would be helpful.

Ludwig

Could you possibly be using a PHP extension in the environment that the class was not working as expected, that supposedly optimizes the execution of the PHP code, like Zend Optimizer, Turck MMCache, eAccelerator?

That could explain why the code could be working erroneously.

Hi,

yes, on the dev server are a few extensions:
with Zend Extension Manager v1.0.10, Copyright (c) 2003-2006, by Zend Technologies
with Zend Optimizer v3.0.0, Copyright (c) 1998-2006, by Zend Technologies
with Zend Download Server v1.0.6, Copyright (c) 2003-2005, by Zend Technologies
with Zend Platform v2.1.2, Copyright (c) 1999-2006, by Zend Technologies
with Zend Debugger v5.2.0, Copyright (c) 1999-2006, by Zend Technologies

this would explain why it only happens on the dev server. Thanks for pointing this out to me.

Ludwig

Unfortunately PHP Optimizer extensions are not trustworthy. It is not specifically a problem with Zend Optimizer. I already had apparent bugs reported about other classes that were due to having other optimizer extensions turned on.

You do not need to disable Zend Optimizer extension completely. You will need it to load PHP code encoded with Zend Encoder. I suggest that you just disable the optimizing options of Zend Optimizer in php.ini. This way you can still use other features of Zend Optimizer extensions.

Meanwhile, I may just rearrange the code of the forms class as you suggested to avoid that apparent bug of Zend Optimizer.