Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: "Lothan" To: "Jean Delvare" , "Larry Hall \(RFK Partners Inc\)" Cc: Subject: RE: file descriptors opened as text files Date: Thu, 15 Feb 2001 21:07:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 > From: cygwin-owner AT sources DOT redhat DOT com > [mailto:cygwin-owner AT sources DOT redhat DOT com]On Behalf Of Jean Delvare > Sent: Thursday, February 15, 2001 6:37 AM > To: Larry Hall (RFK Partners Inc) > Cc: cygwin AT sources DOT redhat DOT com > Subject: Re: file descriptors opened as text files > > Yes, b is fine when opening a file *handle* with fopen(). But I am working > with a file *descriptor* returned by open(), which is quite different. > open()'s behavior is ruled by a bunch of O flags such as O_RDONLY, > O_WRONLY and so on. Linux's man page for open(2) don't specify any flag > for text or binary mode. But I grep'ed Cygnus' includes for any O flag > and I could see that there are O_BINARY and O_TEXT flags defined. Using > O_BINARY solves my problem, indeed. > > Now that everything works for me, I'd like to share my point of view on > the subject. > > Having file handles open the files in text mode as a default behavior > doesn't sound that bad. It is the way all systems act, and the "b" flag is > standardized. > > But file descriptors being concerned, cygwin's behavior is just weird (my > opinion). The file desciptor is the lowest access level to the files. In > the unix world (the real one) there is simply no text mode defined for > file descriptors (which makes my program using O_BINARY unportable). It > looks like a Cygnus' invention, and will probably cause lots of trouble to > any developper porting applications using file descriptors - and there > must be a lot. I don't even think this behavior is POSIX compliant (but I > don't know how to check it). Cygwin's behavior makes perfect sense if you consider all the hoops it has to go through to maintain compatibility with *nix and POSIX. It attempts to solve the problem of enabling *nix tools to work as cleanly and easily as possible in a Windows environment where everything is terminated with CR/LF line endings. The other possibility is to make binary mode the default and answer every third question with "Did you strip the CR's from the file first?" It does not solve every problem with line terminators, of course, but they are significantly reduced. The O_BINARY and O_TEXT extensions may or may not be POSIX compliant, but Cygwin is not the only platform that offers these extensions. Your compatibility concerns are easily handled with a simple #ifdef __CYGWIN__ around the appropriate code. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple