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 -- [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html