From mboxrd@z Thu Jan 1 00:00:00 1970 From: Earnie Boyd To: Jean Delvare Cc: "Larry Hall (RFK Partners Inc)" , cygwin@sources.redhat.com Subject: Re: file descriptors opened as text files Date: Thu, 15 Feb 2001 08:04:00 -0000 Message-id: <3A8BFE21.F9F0EC36@yahoo.com> References: X-SW-Source: 2001-02/msg00888.html Jean Delvare wrote: > > > Said it before but I'll say it again. In the absence of mount points, > > Cywgin adopts defaults which it will use if it needs to. That's text mode > > in this case. > Agreed. > > > "b" is fine, as you indicated before. Check the MSDN library at > > msdn.microsoft.com for one source. I'm sure you can find this information > > in any POSIX complaint UNIX API reference. > 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 sounds as if you need to do a Google search. O_BINARY is not a Cygnus invention as you suppose, it is a technology standard. The typical advice for portability using the flag is #ifndef O_BINARY #define O_BINARY 0 #endif and then your program becomes portable to all systems. > 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). > Searching the net for information is a great advance in technological research you should learn to take advantage of it. > Here it is. Feel free to react ;) > > Another point to be corrected : > Strip doesn't work as other tools regarding file's .exe extension. > Consider these lines in a Makefile : > > strip : prog1 > strip prog1 > > Consider we have prog1.exe compiled in the directory. Typing 'make strip' > won't complain about a missing 'prog1' and understands that it refers to > 'prog1.exe', but then strip complains that it won't find 'prog1'. > It really sound like something needing to be corrected, isn't it? > Feel free to post patches. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple