[PATCH] open O_TEXT and O_BINARY for cygwin/windows
vherva at niksula.hut.fi
Sat Jan 25 10:12:01 EST 2003
On Sat, Jan 25, 2003 at 01:43:39AM -0800, you [jw schultz] wrote:
> On Sat, Jan 25, 2003 at 10:56:37AM +0200, Ville Herva wrote:
> > On Fri, Jan 24, 2003 at 05:09:43PM -0600, you [Dave Dykstra] wrote:
> > >
> > > I think I'll go ahead and put in your patch with the modification of
> > > using O_TEXT_STR as you suggest.
> > Thanks.
> > > I think the risk is low.
> > I think so, too.
> > > I had been concerned that perhaps older CPPs might not be able to
> > > handle that syntax, but I see other places in the rsync code that are
> > > depending on it so I think it's OK.
> > I think it is standard C, but OTOH looking at for example
> > http://www.chris-lott.org/resources/cstyle/portableC.pdf reminds that
> > not all ancient C preprocessors are compliant. But, with such ancient
> > beast, I think a lot of other things would break, too.
> fopen() spec per SUSv3 (IEEE Std 1003.1-2001) which supercedes POSIX:
> Annotations therewith indicate that this is aligned with the
> ISO C standard and any conflict is unintentional and defers
> to the ISO C standard.
To clear any confusion:
With "I think it is standard C" I wasn't referring to use of "rt" per se but
to the macro trick I suggested earlier in this thread (and to which Dave
agreed to). Namely:
#define O_TEXT_STR "t"
#define O_TEXT_STR ""
fopen(filename, "r" O_TEXT_STR);
Dave brought up his concerns about the use of C preprocessor string
catenation, but noted that the same trcik is already used elsewhere in rsync
Of course, whether O_TEXT is defined or not does not necessarily imply the
availability of "t", but I can't think of better alternative.
> What i don't see here is any mention of the "t" option. "b"
> is explicitly permissable which would imply "t" is otherwise
But it isn't on Cygwin, at least when the mount is of "binary" type.
> Curiously, the spec does not permit fopen to fail if the mode argument
> contains unrecognized characters. The only failures permitted related to
> mode have to do with access privileges.
Well, that is good.
> SUSv3 does not show the availability of a O_BINARY or O_TEXT
> mode for open() which makes sense. Text/binary handling is
> not the responsibility of the OS and open() is a system call.
> I think you will need the macros for the open() calls.
-- v --
v at iki.fi
More information about the rsync