Bug 72752

*** This bug has been marked as a duplicate of 72551 ***

Argh wait this is for 7.2 not current beta.. sorry

Looking at this again

Ok, lets have a look at the following screen cuts.

First off what level of php are we using...
[root@alpha root]# rpm -q php
php-4.1.2-7.2.4

Current errata for 7.2 good...
And we'll be using the following to dump out variables.

[root@alpha root]# cat /var/www/html/test.php 
<?php
reset($_GET);
var_dump($_GET);
?>

The test is to toggle register_globals=On/Off and note if there are any
differances when passing in a NULL variable 
ie
1 - http://localhost/test.php?a=1&b=2&c
2 - http://localhost/test.php?a=1&b=2&c=
3 - http://localhost/test.php?c&b=2&a=1
4 - http://localhost/test.php?c=&b=2&a=1

Results when register_globals=On (line 302 /etc/php.ini)
1 array(2) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" }
2 array(3) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" ["c"]=>  string(0) "" } 
3 array(2) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" }
4 array(3) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" ["a"]=>  string(1) "1" }

Results when register_globals=Off
1 array(2) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" }
2 array(3) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" ["c"]=>  string(0) "" }
3 array(2) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" } 
4 array(3) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" ["a"]=>  string(1) "1" } 

Thers actually no differance between register_globals=On/Off so thats a red
herring. On the more annoying side, though probably more sensible, variable
count is being calculated on the number of ='s (Note how a=1 drops off the
argument list when the first param has no '=' associated with it.)

Lemme see if ?var without an = is valid html

Ok, so having asked around,
http://localhost/test.php?a
IS legal, however, HTML forms NEVER write ?a but rather ?a=

Strictly speaking, yes, this is a bug but it's not one thats likely to
obliterate php scripts from working as in normal operation html forms pass in
the '=' appended to undefined variables. I'm passing this upstream to the php folk.

Kicked upstream as

http://bugs.php.net/bug.php?id=19131

Reopening

Seems we need this little gem:
http://cvs.php.net/diff.php/php4/main/php_variables.c?r1=1.35.2.1&r2=1.38&ty=u&Horde=f49512db3e843ec2d787d53cd6ffa5a2

Phil
=--=

... and some testing shows that this doesn't help things.. doh...

..except their fix is buggy,.. NULL should be "" ...

fixing,..
compiling,..
testing,..

still craps out.
Humm, something else is amiss.

Phil
=--=

.. and I see upstream has now said 'use latest cvs'...
bah...

*** Bug 72921 has been marked as a duplicate of this bug. ***

Latest cvs dies during compile...
waiting for next snapshot

Phil
=--=

Ok so 4.3.0-dev (200208291500 cvs snapshot) seems to come through without too
much problems.

[root@alpha root]# ./test.php "&valueone=testone&valuetwo=testtwo&fred="
Status: 200
Content-type: text/html
X-Powered-By: PHP/4.3.0-dev

test1 = [testone]
test2 = [testtwo]
array(4) {
  ["_/test_php+"]=>
  string(0) ""
  ["valueone"]=>
  string(7) "testone"
  ["valuetwo"]=>
  string(7) "testtwo"
  ["fred"]=>
  string(0) ""
}

Now then,.. thers no way I'm going to ship 4.3.0-dev cvs snapshots in the dist.
Just ain't going to happen. So the question becomes what the heck changed that
makes it work, makes the diffs and shove it in an errata/upcoming release
(present in 4.2.2)

Phil
=--=

Ok,.. after a lot of tinkering around, this looks related to --enable-mbstring
and --enable-mbstr-enc-trans being enabled during the build.

These were enabled to help support multibyte language entry but as it appears to
be broken, I think the correct action should be to remove them. By itself this
isn't actually enough. You also need this small patch to
php-4.1.2/main/php_variables.c


[root@alpha main]# diff -u php_variables.c.orig php_variables.c
--- php_variables.c.orig        Fri Aug 30 13:01:40 2002
+++ php_variables.c     Fri Aug 30 13:02:53 2002
@@ -297,6 +297,8 @@
                        php_url_decode(var, strlen(var));
                        val_len = php_url_decode(val, strlen(val));
                        php_register_variable_safe(var, val, val_len, array_ptr
TSRMLS_CC);
+               } else {
+                       php_register_variable_safe(var, "", 0, array_ptr TSRMLS_CC);
                }
                var = php_strtok_r(NULL, separator, &strtok_buf);
        }



All those in favor of removing the two compile options, and getting back to php
acknowledging all the variables passed to it, say 'aieee'

aieee!

Removed. Errata built, passed to QA for testing.

[root@alpha main]# ../php /root/test.php "&a=1&b=2&c"
X-Powered-By: PHP/4.1.2
Content-type: text/html

test1 = []
test2 = []
array(4) {
  ["/root/test_php+"]=>
  string(0) ""
  ["a"]=>
  string(1) "1"
  ["b"]=>
  string(1) "2"
  ["c"]=>
  string(0) ""
}

Ah, forgot, and you'll need this as well for main/main.c

@@ -779,7 +779,9 @@
                int i;
 
                for (i=0; i<NUM_TRACK_VARS; i++) {
-                       zval_ptr_dtor(&PG(http_globals)[i]);
+                       if (PG(http_globals)[i]) {
+                               zval_ptr_dtor(&PG(http_globals)[i]);
+                       }
                }
        } zend_end_try();

Queued up for errata

4.1.2-2.1.5 - Advanced Server
4.1.2-7.0.5 - 7.0
4.1.2-7.1.5 - 7.1
4.1.2-7.2.5 - 7.2
4.1.2-7.3.5 - 7.3

Rawhide
4.2.2-8.0.1 - 8.0

*** Bug 72551 has been marked as a duplicate of this bug. ***

Leaving this open whilst an errata is still pending.

Was this ever fixed?

Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

c) report the bug to the Fedora Legacy project who may wish to
continue maintenance of this package.