|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19131 var_dump seems to be fooled by ?a vs ?a=
Submitted: 2002-08-27 16:29 UTC Modified: 2002-08-29 23:20 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: bryce at redhat dot com Assigned:
Status: Closed Package: Variables related
PHP Version: 4.1.2 OS: Linux (RH 7.2)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: bryce at redhat dot com
New email:
PHP Version: OS:


 [2002-08-27 16:29 UTC] bryce at redhat dot com
Test php script.

[root@alpha root]# cat /var/www/html/test.php 

Test URLS.

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


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" }

Variable count seems to be calculated by the number of ='s (Note how a=1 drops off the argument list when the first param has no '=' associated with it.)

?a is legal html
however as far as I can tell all forms must pass in ?a= to make a valid variable

I'm unsure what to class this as (bug or feature)

It was reported to Red Hat as




Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-27 16:33 UTC] bryce at redhat dot com
Actually I'd like to class it as a bug, even though the first variable (&c) is malformed in test 3 I'd have expected the script to recover the a=1 portion
This behaviour carries on into php 4.2.2

 [2002-08-27 19:25 UTC] pzb at ximian dot com
This appears to be fixed in CVS.  The culprit was a missing else in main/php_variables.c in the 

SAPI_TREAT_DATA_FUNC(php_default_treat_data) function.
 [2002-08-27 22:15 UTC]
Please try using this CVS snapshot:
For Windows:

 [2002-08-29 21:20 UTC] bryce at redhat dot com
Ok current cvs snap works, (well done), HOWEVER, from a distribution point of view I cannot in good faith ship a 4.3.0-dev cvs snapshot. I need to get this fixed for both 4.1.2 and 4.2.2
 [2002-08-29 23:20 UTC]
Just wait for PHP 4.2.3 to be released in about week or so.
(this is fixed in it)

PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Sep 23 03:03:37 2021 UTC