Hi,
using PHP-4.3.6 with PHPEd 3.3.3 under Linux debugging CLI-applications the following problem occurs:

$s = "HALLO";
// $s is now visible in debugger-window "Locals"
$s[0] = "\x00";
// $s is now removed from "Locals"
print $s[1];
// prints 'A', so $s is still there

The problem occured while debugging routines working with fread() returning real zeros as a (binary safe) string from an external device (/dev/ttyS0).

I'm not shure, but the debugger behaves strange after that. Also with other variables in "Locals".

Any ideas?

Thanks a lot in advance,
Volker

I think it's a PHP bug, because PHP 4.3.9 doesn't output any string after '$s = "\x00"'.

Could you please try it with newer PHP version?

What about "binary safe" strings, where a "\x00" does'nt terminate a string? bin2hex($s) works and returns the correct values starting with 00. So I don't think it's a PHP bug. Its more a bug of phped.
If you trace my example, then every other local var also disapears. If you then assign a serious value to $s with i.e. $s="GRR", then all locals appear again. Magic...
I found out, that for the time a 'worse' string is in the scope of DBG, all local vars disappear.

Sorry, I can`t try another version of php, because this version is modified to run better with ncurses.

Thanks a lot,
Volker

I just tried PHP 4.3.11 on FC3...

This is an interesting issue. I did the following:



And viewed the page with Firefox 1.0.4 also on FC3. Firefox displayed the following:



So Firefox doesn't like the null character in there either. However, when I saved the page from Firefox and did a hex dump I got:



Thus, it appears that PHP strings can (or should) be able to handle all 256 characters (meaning binary). It still recognizes the fact that the string has five characters, and aparently doesn't care about whether any character is not in the printable ASCII range. This is a Good Thing IMHO.

Now, when one takes perfectly good binary data and dumps it down a routine that expects printable ASCII text, all bets are off.

If phpEd is like Delphi/Kylix (my favourite development environment), while a Delphi string can handle binary just like a PHP string, a null character will terminate the display of the string in the older versions of the IDE because the underlying APIs that the display components rely on, i.e. the Win32 API, are C-based. C-based APIs think they're done when they hit a null character. I'd have to fire up Delphi, but IIRC at least in version 7 the debugger translates non-printable characters into printable characters before handing them over to the display components. Using the example above I believe D7 would display #0'ELLO' in the debugger.

Considering Firefox goes bonkers trying to display text with null characters, I don't think it's as big a deal. After all, binary down a text pipe is asking for trouble.

Now if the variable is disappearing off of the phpEd debugger display completely, that I would consider a bug since the variable is still active in the local scope. I could argue about whether it should be displaying characters after \x00 (it'd be nice), but the variable should at least still show up in the debugger since it's still in scope.

Wow. Now here's something very odd. I ran the same thing on RHEL4 with PHP 4.3.9.

PHP 4.3.9 behaved identically as PHP 4.3.11 (above).

However, Firefox 1.0.4 running on RHEL4 displayed all characters -- including the null character, which it displayed as a rectangular box. I guess this goes back under the heading of the underlying components and APIs used for display.

This script:

Gives me this output:

when running on PHP 4.3.11. This means, $s was set to empty string on fourth line.

However, I'll add this issue to our bugtracker for further investigation. Thanks for reporting.

Considering that the output you show includes the null character (..."74 0A 00 2D 74"...), $s is not an empty string (i.e. a string of length zero). It was a string of length one, the only charcter being \x00 per the output.

Yes, C would treat this as an empty string, but C would not include '00' in the output either because \x00 in a C-style string is an EOT indicator which is not included in the output... but this is PHP, not C.

Strings in PHP are always binary and are never terminated by 'x00'. The function, which is used to handle the string decides, how to create or use a string. That's why the PHP-documentators differentiate between "string" and "binary safe string" functions.

If you concatinate 2 strings with the operator "." or with "$s-test", they are handled like C-strings terminated by 0. If you use strlen(), the whole binary string is counted. So there is one type of binary string in PHP and it's the function, which decides how to handle the string.
My conclusion: DBG displays strings incorrect. Would be nice to have a fix.

Hi guys,
What are you talking about?
AFAIK, phped 3.3 (build 3397) works perfectly well with strings that contain ZERO(s). See this shot:

Hi ddmitrie,
try it with Linux and phped 3.3.3 (build 3376). It won't work.
Volker