public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jean Delvare <delvare@ensicaen.ismra.fr>
To: "Larry Hall (RFK Partners Inc)" <lhall@rfk.com>
Cc: cygwin@sources.redhat.com
Subject: Re: file descriptors opened as text files
Date: Thu, 15 Feb 2001 06:39:00 -0000	[thread overview]
Message-ID: <Pine.SO4.4.05.10102151515430.1255-100000@e3000.ensicaen.ismra.fr> (raw)
In-Reply-To: <5.0.2.1.0.20010214175309.00a92220@pop.ma.ultranet.com>

> 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

  parent reply	other threads:[~2001-02-15  6:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-14 13:13 Jean Delvare
2001-02-14 13:22 ` Larry Hall (RFK Partners Inc)
2001-02-14 13:40   ` Jean Delvare
2001-02-14 13:58     ` Larry Hall (RFK Partners Inc)
2001-02-14 14:12       ` Jean Delvare
2001-02-14 14:21         ` Larry Hall (RFK Partners Inc)
2001-02-14 14:46           ` Jean Delvare
2001-02-14 15:00             ` Larry Hall (RFK Partners Inc)
2001-02-14 16:54               ` Ross Smith
2001-02-14 19:28                 ` Christopher Faylor
2001-02-15  1:36                 ` Jesper Eskilson
2001-02-15  6:39               ` Jean Delvare [this message]
2001-02-15  7:54                 ` Larry Hall (RFK Partners, Inc)
2001-02-15  9:21                   ` Jean Delvare
2001-02-15  9:24                     ` Larry Hall (RFK Partners, Inc)
2001-02-15 10:37                     ` Christopher Faylor
2001-02-15  7:59                 ` DJ Delorie
2001-02-15  9:12                   ` Jean Delvare
2001-02-15  9:17                     ` Larry Hall (RFK Partners, Inc)
2001-02-15  9:28                       ` Jean Delvare
2001-02-15  9:37                         ` Larry Hall (RFK Partners, Inc)
2001-02-15 10:38                         ` Christopher Faylor
2001-02-15 10:11                     ` Earnie Boyd
2001-02-15  8:04                 ` Earnie Boyd
2001-02-15  9:30                   ` Jean Delvare
2001-02-15  8:04                 ` Corinna Vinschen
2001-02-15 21:11                 ` Lothan
2001-02-14 15:04             ` Christopher Faylor
2001-02-14 14:21         ` Christopher Faylor
2001-02-14 14:30           ` Jean Delvare
2001-02-14 14:40             ` Christopher Faylor
2001-02-14 14:51             ` Larry Hall (RFK Partners Inc)
  -- strict thread matches above, loose matches on Subject: below --
2001-02-15 15:53 Heribert Dahms
2001-02-15 16:06 ` Larry Hall (RFK Partners, Inc)
2001-02-15 18:26   ` Christopher Faylor
2001-02-16  8:12 ` Ehud Karni
     [not found] <BF35D9C143BCCC4EB63181B67C9320C804DD0F@serv-075.icon-germa>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SO4.4.05.10102151515430.1255-100000@e3000.ensicaen.ismra.fr \
    --to=delvare@ensicaen.ismra.fr \
    --cc=cygwin@sources.redhat.com \
    --cc=lhall@rfk.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).