[PATCH] open O_TEXT and O_BINARY for cygwin/windows

[Ville Herva]

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:

#ifdef O_TEXT
#define O_TEXT_STR "t"
#else
#define O_TEXT_STR ""
#endif

and then

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

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

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