I believe this is caused by a comparison to an uninitialized buffer in php_read (buffer emalloc'd in socket_read).

Patch:

--- php5/ext/sockets/sockets.c  2003-01-18 19:28:06.000000000 +0000
+++ php5-atropine/ext/sockets/sockets.c  2003-02-05 15:43:00.000000000 +0000
@@ -288,6 +288,7 @@
 
        set_errno(0);
 
+       *t = 0;
        while (*t != '\n' && *t != '\r' && n < maxlen) {
                if (m > 0) {
                        t++;

I can repeat this bug.

here is an example script that i used:
http://force-elite.com/~chip/test/socket_phpreadnormal.phps

it is a modification of the basic HTTP client given as an example in the PHP.net documentation.

When PHP_NORMAL_READ is used, and certen buffer sizes, it will resuilt in socket_read returning bogus data, commonly all newlines(\n).

On both a FreeBSD-4.7-stable(built Fri Nov 29), and FreeBSD-5.0-RC(built Wed Jan 8), both using PHP-4.3.0-cli, with a buffer size of 2048 it would work, with a buffer size of 100, socket_read() would return a stream of \n.

On Linux 2.4.18-18.7.x(Redhat Box) using PHP-4.3.0-cli, it would always work, regardless of the buffer size.

On Linux 2.4.19-crypto-r7(Gentoo Box) using PHP-4.3.0-cli, it would work with 2048 buffer size, but with 100 it would bail with:
Notice: Undefined offset:  0 in /path/socket_phpreadnormal.php on line 51
Warning: socket_read() expects parameter 1 to be resource,
null given in /path/socket_phpreadnormal.php on line 51
(I don't have direct access to this box, I didn't want to heavly debug it, it is possibly an error in my script.)

On Windows 2000, using PHP-4.3.0-cli, it would always return 0(EOF) from socket_read(). It Bailed with:
Warning: socket_read() unable to read from socket [0]: The operation completed successfully.
(perhaps a seperate bug :-) )

ah. found my windows 2000 socket_read bug:
http://bugs.php.net/bug.php?id=21197

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

Works fine here with latest stable CSV.
The path you prose is bogus because it overwrites the 1st byte in t with a 0.

I have the same problem with this function with PHP 4.3.4 on FreeBSD 4.9. (The file sockets.c is exactly the same in this version of PHP and in php4-STABLE-200402241230.)

I think the patch suggested by "uce at ftc dot gov" looks like the simplest solution. Contrary to what iliaa@php.net indicate, this patch does not in any way affect the result returned to the user, except for fixing this bug.

I'm not at all surprised that iliaa@php.net was unable to reproduce this bug, because it only occurs if the buffer returned by emalloc() in socket_read() begins with '\r' or '\n', and that is not neccessarily the case, depending on configuration and operating system.

I don't think I have commit access to the sockets extension, but I hope that somebody who has can fix this.

Regards,

David Eriksson

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.