John Cowan <cowan <at> ccil.org> writes:
> Are you saying that an O_TEXT open under Cygwin, given a binary mount,
> will cause newline translation? I had assumed that O_TEXT would be
> ignored under Cygwin just as it is under Linux.
Yes. The cygwin behavior is as follows:
open(O_RDONLY), fopen("r") - open the file using the mount point rules to
decide whether the file is text or binary
open(O_RDONLY|O_BINARY), fopen("rb") - open the file forced in binary,
regardless of mount point
open(O_RDONLY|O_TEXT), fopen("rt") - open the file forced in text, regardless
of mount point
pipe() - create pipe with mode determined by CYGWIN env variable (default setup
is binary, but if $CYGWIN includes "nobinmode", pipe becomes binary)
binary mode reads the file as is, text mode strips all \r and ends the file at
the first ^z.
freopen(NULL, mode, stream) - works to swap existing mode of an open fd-based
stream between text and binary (but currently fails on special streams, such as
from fmemopen)
#include <io.h>
setmode(fd, <0, O_BINARY, or O_TEXT>) - works to swap existing mode of an open
fd, as well as any open stream based on that fd (using 0 restores mount point
default mode)
>
> That said, I believe it is good for portability to use O_TEXT
> and O_BINARY (and their stdio equivalents) in all software intended
> to be portable.
Using O_BINARY is important, however, I claim that using O_TEXT in portable
code should be a very rare circumstance. There's a reason that C99 only calls
out fopen("r") and fopen("rb"), but not fopen("rt").
--
Eric Blake
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
