Re: dd and binary mode

[Paul Eggert]

address@hidden (Eric Blake) writes:

> After further thought and discussion on the cygwin list, I'm convinced
> that dd should default to binary mode (on non-ttys) on systems that
> have a distinct text mode.

That sounds reasonable, but I'm beginning to worry that the code is
becoming more ad-hoc and hard to maintain.

This isn't just dd; it's cat, md5sum, split, etc.  And I don't really
understand how it works, or why some programs use binary modes and not
others.  For example, POSIX says that the input to "head" must be a
text file, so why does GNU "head" set binary mode?  Why does (say)
"unexpand" use binary mode, but "uniq" uses text mode?  Why does
md5sum invoke setmode (..., O_TEXT) on a file that has just been
fopened with "r" (doesn't that mean text?).  None of this stuff really
makes sense to me, and this makes the code hard to maintain.

Is there some way that we can simplify this by using wrapper functions
on DOS-like hosts?  I'd rather get rid of the SETMODE and SET_BINARY
macros entirely.  If Cygwin open or fcntl doesn't do the obvious thing
with O_TEXT and O_BINARY, let's define a wrapper function, used only
on cygwin, that does the right thing.

> But on cygwin, setmode can return -1 on failure with EBADF or EINVAL.

Would it ever do that with the arguments we present to it?  If not,
I wouldn't worry about it.

Your patch assumes that (O_BINARY != 0 && O_TEXT != 0); is this really
true on all platforms?  It seems to me that one could be zero.