It should probably go into the engine.
--Wez.
On Apr 8, 2005 7:46 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Not sure. Wez or Sara know that part of the code best.
> I'll refrain from applying to the Zend Engine then or should I apply that
> patch anyway? It seems quite harmless either way...
Not sure. Wez or Sara know that part of the code best.
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
Yeah, popen is tricky to replace.
A workaround for solaris is to use proc_open() in the scripts instead.
Other extensions that might have issues are those that will accept a
stream to use as a source for data. Off the top of my head, you'll
want to check the PDFlib and ming extensions. Actually,
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
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
