Re: [PATCH] Add renameat2 function [BZ #17662]

[Florian Weimer <fweimer at redhat dot com>]

On 07/05/2018 04:24 PM, Paul Eggert wrote:
> Thanks, everything looks good, except for one nit in the NEWS patch, 
> which says:
>
> > If the flags are zero, the renameat2 function is implemented using 
> > renameat.  If the flag is not zero and there is no kernel support for 
> > renameat2, the function will fail with an errno value of EINVAL.
>
>
> If the flags are zero, renameat2 is not always implemented using 
> renameat. Also,
> I found that second sentence confusing (it doesn't say what happens if 
> there is kernel support). How about the following text instead?
>
> ---
>
> If the flags are zero, the renameat2 function is equivalent to renameat. 
> Otherwise, it uses the renameat2 system call if kernel support is 
> available, and fails with an errno value of EINVAL otherwise.

Hurd doesn't have system calls, so I'm not sure if this language is 
appropriate.  So I would like to use this:

* The renameat2 function has been added, a variant of the
  renameat function which has a flags argument.  If the flags are
  zero, the renameat2 function acts like renameat.  If the flag
  is not zero and there is no kernel support for renameat2, the
  function will fail with an errno value of EINVAL.  This is
  different from the existing gnulib function renameat2, which
  performs a plain rename operation in case of a RENAME_NOREPLACE
  flags and a non-existing destination (and therefore has a race
  condition that can clobber the destination inadvertently).

Thanks,
Florian