Mail Archives: cygwin/2001/02/15/11:39:43
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
- Raw text -