Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26613 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55593 invoked by uid 1010); 15 Nov 2006 18:56:08 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 55559 invoked from network); 15 Nov 2006 18:56:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Nov 2006 18:56:08 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=good Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.172 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 66.249.92.172 ug-out-1314.google.com Linux 2.4/2.6 Received: from [66.249.92.172] ([66.249.92.172:58664] helo=ug-out-1314.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/00-53553-4A26B554 for ; Wed, 15 Nov 2006 13:55:34 -0500 Received: by ug-out-1314.google.com with SMTP id 80so209683ugb for ; Wed, 15 Nov 2006 10:55:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=it4bIQpqMwaTyKLgP2W75RpW5oGTFJgW/6zRsb7jMz8dglKE/OHi/8JA+3NkXUG/8K2wTu+2qA713+dIyJJfcAeJffIZpXySCq48ReenGMuGVBHes5tHqFHFe1XWTo9/jdI/cJ/85ahVXX5VYofk/HkdEowSPA/ISaOp+AU6SpE= Received: by 10.78.17.1 with SMTP id 1mr608677huq.1163616929357; Wed, 15 Nov 2006 10:55:29 -0800 (PST) Received: by 10.78.137.6 with HTTP; Wed, 15 Nov 2006 10:55:29 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 19:55:29 +0100 To: "Wez Furlong" Cc: php-dev , "Dmitry Stogov" In-Reply-To: <4e89b4260611151037r6529e142w349440bf5f5c1843@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4e89b4260611151037r6529e142w349440bf5f5c1843@mail.gmail.com> Subject: Re: Windows SAPI possible binary file operation bug and possible fix From: pierre.php@gmail.com (Pierre) Hello, On 11/15/06, Wez Furlong 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