Re: file descriptors opened as text files

[Earnie Boyd <earnie_boyd@yahoo.com>]

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