Re: Windows SAPI possible binary file operation bug and possible fix

From: Date: Wed, 15 Nov 2006 18:55:29 +0000
Subject: Re: Windows SAPI possible binary file operation bug and possible fix
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-26613@lists.php.net to get a copy of this message
Hello, On 11/15/06, Wez Furlong <kingwez@gmail.com> wrote:
We cannot change it in SAPI where we are not the .exe because we don't own the process. Messing with that flag affects the entire process and could break things at a higher level. I call this kind of thing "library abuse", where one piece of code assumes that it is the only consumer of the library. In a modular application, this is not the case. I think your actual bug is elsewhere, and that the binary flag isn't being explicitly set on a stdio file handle somewhere in the zip library code.
As I said, it uses "b" everywhere. It is a windows bug. Many other projects do the same trick to get the problem solved. I'm not sure if it affects the non binary mode or if it only fixes the binary mode. I think fopen still works as expected in non binary mode.
I'm -1 on making this change to the other SAPI.
Why do we use it in FGCI, CLI and embed? The impact on the other libraries used by the PHP process is the same, even if it does not affect the server.
Incidentally, using stdio is not portable in a server application that might have more than 255 open files at one time. Best to use the streams layer throughout if possible.
Not possible right now but it is in the Todo, I'm not sure it will fix the problem either, unless I use parse_mode and php_stream_fopen(); --Pierre

« previous php.internals (#26613) next »