I'll refrain from applying to the Zend Engine then or should I apply that patch anyway? It seems quite harmless either way...
Andi
At 04:58 PM 4/8/2005 +0200, Uwe Schindler wrote:
OK - I found out that the fdopen() code is never called in the PHP environment, so patch is not needed (PHP sets zend_file_handle always to STREAM). But I still want to know for what extensions/functions the casts from posix to stdio are needed- Will casting appear somewhere when the user calls the userlevel-file-functions starting with fopen()?. It is hard work to find out with simple search through CVS.
The only position I know is because of popen() etc. in the exec functions which are stdio (posix variants are more complicated), which is the cause for the bug report I mentioned.
At 09:40 07.04.2005, Uwe Schindler wrote:I am fixing bug #32614: Problem, on the solaris platform fdopen() can fail even if fd is a correct file descriptor, when fd>255 (the well-known solaris stdio problem). The webserver of the user crashes because the return value of fdopen() is not checked for NULL when casting a stream from posix to stdio. After this fd==-1 and fp==NULL ==> further calls to fread/fwrite with this fp segfault.
I committed the patches for PHP but I have no karme for "ZendEngine2". Can someone with karma submit this patch?
According to this it would be interesting, WHEN some PHP/Zend code tries to cast a POSIX stream to stdio? In which extension/functions? Can this be fixed to only use posix IO? The zend engine itself should be safe since 4.3.3 and since PHP5.
Does stream casts apply if a user uses the PHP user functions fopen, fread, fwrite? Since Saschas fix in PHP4 there this does not happen. What about PHP5?
I would try to fix this everywhere in the future.
----- Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
----- Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
