This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: file descriptors opened as text files



> 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
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).

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?

-- 
       /~~       Jean "Khali" Delvare
  -----\_                        mail: delvare@ensicaen.ismra.fr
 --------\                http://www.ensicaen.ismra.fr/~delvare/
---=ISMRA/- ____________________________________________________


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]