On 10/12/02, "Ilia A." <[EMAIL PROTECTED]> wrote: > #0 0x403cd271 in ?? () > #1 0x8171922 in zif_fgets (ht=2, return_value=0x83c843c, this_ptr=0x0, > return_value_used=0) at /home/rei/PHP_CVS/php4/ext/standard/file.c:1271 > #2 0x823faa2 in execute (op_array=0x83d498c) at > /home/rei/PHP_CVS/php4/Zend/zend_execute.c:1597 > #3 0x822c9e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at > /home/rei/PHP_CVS/php4/Zend/zend.c:839 > #4 0x81f2d81 in php_execute_script (primary_file=0xbffff6b0) at > /home/rei/PHP_CVS/php4/main/main.c:1542 > #5 0x8250b47 in main (argc=2, argv=0xbffff734) at > /home/rei/PHP_CVS/php4/sapi/cli/php_cli.c:695 > #6 0x403bdf5c in ?? ()
That bt looks like it's missing some symbols. > The core is actually intentionally done by emalloc(), which terminates > execution when it cannot allocate requested memory. That is correct > behaviour, what is not correct is that fread() tries to blindly allocate that > much data without actually seeing how much data there is on a socket. > I realize that doing one emalloc() is faster then doing many ereallocs() to > increase the buffer when its size is reached. However, the latter IMHO is the > correct behaviour not to mention that it works correctly in PHP 4.2.3 and > lower. Now that's interesting, because there is no difference in the memory allocation strategy between 4.2.x and HEAD/4.3. Perhaps there has been a change in ZE somewhere? This isn't really a streams issue, particularly with fgets, because it is just not possible to guess how many bytes are needed for a line prior to reading it, which is the reason for having the user specify the buffer size. I agree that it should not segfault, but I don't think that it makes sense for fgets or fread (or any of the other functions that accept buffer sizes from the user) to perform sanity checks on buffer sizes; that's the memory managers job. --Wez. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
