not reproducible in latest PHP 5 CVS.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Folks, this seems to be a real bug 64 bit related I think

since the OP test in x86 says me:

string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

the expected result, Hoever in my linux amd64
I get

string(38) "x%DAs%CE%CF-%28J-.V%C8M%05%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

if this is not a bug,It have an unconsistent behaviuor...

odd.. Im getting other different result with a 10 minutes ago   source code from the CVS  (in amd64)

string(42) "x%DAs%CE%CF-%28J-.V%C8M%05%5C0%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

the previuos result mentioned was from my system PHP compiled yesterday... :S

Somebody needs to change the summary, and the PHP version, It can be reproduced with 5.1.3-dev CVS.

I've still got this problem. (this was not the subject of the below conversation)



11:51 < rasmus> main/php_variables.c has the php_default_treat_data() function which implements the actual default string 
                parsing logic in PHP.  And no, you can't change it.  It would break every PHP app ever written
...
11:52 < rasmus> the point is that it isn't broken
11:53 < rasmus> and if you think it is, then you are simply wrong.
11:53 < EvanCarroll> http://www.google.com/search?q=site%3Abugs.php.net+parse_str&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
11:54 < rasmus> your point?
11:54 < rasmus> those are all people who don't understand how to use it
11:54 < rasmus> like I said, it is exactly the same code as PHP uses to parse incoming user data
11:55 < rasmus> and it adheres to all the same rules


Apparently, not reviewing the bug tracker is an indicator that everyone else doesn't know what they're doing.

32bit build

Works fine on 64-bit Linux with PHP 5.2.10
Also fine on 32-bit OSX with PHP 5.3.0

So, if you still see this problem, please be more specific about your PHP and OS versions.

ecarroll@x60s:~$ php --version
PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23 2009 14:35
:05) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
ecarroll@x60s:~$ md5sum /usr/bin/php5
5c83d3bd430c8673a9124c3adbb662f5  /usr/bin/php5

This is packaged php5 that Ubuntu ships with. It might be the Suhosin patch that is causing this problem.

(Ubuntu 9.04 Jaunty)

Running the above code on my Ubuntu Jaunty 32bit does *not* exhibit the reported behaviour:

Linux puffy.pgregg.com 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux

PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Jun  7 2009 22:28:42)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with Suhosin v0.9.24, Copyright (c) 2007, by SektionEins GmbH

string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

I am pretty sure this is fixed by my patch from 9 months ago:
http://cvs.php.net/viewvc.cgi/php-src/main/php_variables.c?r1=1.104.2.10.2.12&r2=1.104.2.10.2.13&pathrev=PHP_5_2

If someone can reproduce this in any PHP version after 5.2.6, let me know and I will re-open.