O_RSYNC and O_DSYNC

[Corinna Vinschen]

Hi Joel,

On Nov 23 08:37, Joel Sherrill wrote:
> Hi
> 
> Looking through old RTEMS PRs, someone reported these
> are missing in newlib. If no target has needed them
> should we add them for completion?
> 
> If so, Linux has them wrapped like this:
> 
> #if __USE_POSIX1999309 || defined __USE_UNIX98
>   #define O_DSYNC XXX
>   #if defined(__O_RSYNC)
>     #define O_RSYNC __ORSYNC
> #else
>     #define O_RSYNC XXX
> #endif
> #endif
> 
> How/if should we guard the definitions of O_RSYNC/O_DSYNC?
> Open Group just cites them as C Library extensions. Linux is
> marking is as 1999. Does that correspond to newlib's
> __XSI_VISIBLE >= 600?

Hmm, good question.  What about __POSIX_VISIBLE >= 199309?

> Should I just pick the next logical values in sys/_default_fcntl.h
> around line 25 and add these around 45?

Have a look at lines 48-50.  These are already defined for ages on
Cygwin (no idea, though, who thought _WIN32 would ever be useful).

Cygwin also defines additional values in its own fcntl.h, and you never
know if other targest define their own values, too.  It would be nice
not to introduce clashing values in the default fcntl header.

Here's what Cygwin defines in /usr/include/fcntl.h:

  /* sys/_default_fcntl.h defines values up to 0x40000 (O_NOINHERIT). */
  #define _FDIRECT        0x80000
  #define _FNOFOLLOW      0x100000
  #define _FDIRECTORY     0x200000
  #define _FEXECSRCH      0x400000

  #define O_DIRECT        _FDIRECT
  #define O_NOFOLLOW      _FNOFOLLOW
  #define O_DSYNC         _FSYNC
  #define O_RSYNC         _FSYNC
  #define O_DIRECTORY     _FDIRECTORY
  #define O_EXEC          _FEXECSRCH
  #define O_SEARCH        _FEXECSRCH

As you can see, O_DSYNC and O_RSYNC are == O_SYNC == _FSYNC.

Given the potential implementation differences between targets and given
their state as optional in SUSv4, shouldn't the definitions stay outside
of sys/_default_fcntl.h?

Also, for 16 bit targets the O_DSYNC and O_RSYNC values, as well as any
other value, should override values from lines 10 to 25 not used in the
open call (_FMARK, _FDEFER, etc), otherwise we're out of 16 bit flag values.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20141124/fa82ff12/attachment.sig>