Have a closer look at

   http://bugs.php.net/bugs.php?id=1971

and the commentary of Zeev. You have to
use unset($GLOBALS["x"]);

-- 
Bj?rn Schotte                        b.schotte@pangora.com
http://rent-a-phpwizard.de/          bjoern@baer.main.de

Thats thanks to Bjorn ;) Not my sig..

Of course I know that it is already documented. First mentioned in August 1999!

Havn't mentioned this, cause it is not relevant. A bug is bug, and the other tickets have been closed, but the bug was remaining.

4 (or more?) other guys had the same trouble with this behaviour. How many others havn't reported this bug? I know minimum 2 others, which havn't.

Sorry, but it IS a bug and a workarround is not a bugfix and my opinion is, that you make it too easy for yourself to change the state of this ticket to "closed".

But I will not change it for you. I'll respect your decission.

The mentioned workarround (unset($GLOBALS['x'])) dosn't work with my testscript.

The result is exactly the same as with the first version of my script. I really have GREAT TROUBLES to upgrade this old application to PHP4.

Result:

'/hugo/bla/fasel'
'/hugo/bla'
'/hugo'
DIR called with function test1(): Array ( [/hugo] => 1 [/hugo/bla] => 1 [/hugo/bla/fasel] => 1 ) 
'/hugo/bla/fasel'
'/hugo/bla'
'/hugo'
DIR called with function test2(): Array ( [/hugo/bla/fasel/test] => 1 [/hugo] => 1 [/hugo/bla] => 1 [/hugo/bla/fasel] => 1 ) 


Script:
<?

function test1 ($dir) {
GLOBAL $x;
        unset($GLOBALS["x"]);
        $x[$dir]=true;
        mydirname($dir);
}


function test2 ($dir) {
GLOBAL $x;
####### unset($x);   no unset!
        $x[$dir]=true;
        mydirname($dir);
}

function mydirname ($dir) {
GLOBAL $x;
        $dir=ereg_Replace('/[^/]*$','',$dir);
        if (!empty($dir)) {
                echo "'$dir'<br>"; flush();
                mydirname($dir);
                $x[$dir]=true;
        }
}

$dir="/hugo/bla/fasel/test"; # first char must be '/' !

unset($x);
test1($dir);
echo "DIR called with function test1(): "; print_r($x);

echo "<br>";

unset($x);
test2($dir);
echo "DIR called with function test2(): "; print_r($x);

?>

This isn't a bug, but a feature =)

If you use GLOBAL within a function it creates a reference to the orignal variabele, this reference is local to the function. SO if you unset() this variabele, you're only unsetting the reference (and thus not the GLOBAL variabele). This is documented behavior (from the unset() manual page):

   If a globalized variable is unset() inside of a function, only the
   local variable is destroyed. The variable in the calling environment
   will retain the same value as before unset() was called.

Sorry... forgot to read all the comments....

Bug or feature. Thats the question. :)

Sorry, it IS a bug. 4 people have mentioned this and I found now a
test case, where no workarround exists.

But I found another problem in this context. Will make a new ticket.

So, what's the problem with your latest code? I do not see any.

My problem is, that old PHP3 scripts won?t work with PHP4, if they use such a construct.

And it is a bug in the meaning of "the program dosn't do, what I expect". Ok, the bug is documented, but look at the ERROR-ID #8972 for a case, that makes a much more surprising and unexpected effect.

Why can't PHP just overwrite the value with the value "UNSET" in the case of unsetting a reference - instead of removing the reference?

"the program dosn't do, what I expect"
 is not a bug. A bug is "the program doesn't do what the
programmer expected". If 'man' program doesn't create a
little man to help you with your C code, it's not the
program's fault :)

And no, it cannot work the way you proposed, because there's
no way to discover what that "other" variable, that $foo is
linked to, was in the first place. It's located in another
symbol table, which is not available in that function. But
if you don't really need unset (which wipes the variable
completely), you could just use something like $foo=false,
which does work on references perfectly.