Carlos O'Donell wrote:
On 07/04/2018 03:35 PM, Paul Eggert wrote:
You position Gnulib's implementation as having no drawbacks
That certainly was not my intent. The Gnulib implementation has known race
conditions on platforms whose kernels don't promise atomicity. It's just that
Gnulib-using applications prefer this drawback to implementing racy subsititutes
themselves.
Not every racy API is a bug. (If it were, we'd have to abolish stdio. :-)
I have no objection to a racy API with another name.
Yes, that is direction we're heading.
we still haven't
run into a GNU app that actually *requires* atomicity.
coreutils *requires* it to solve the race
Sure, but Coreutils doesn't *require* atomicity to build and run just as well
has it has run for decades. All Coreutils *requires* is the Gnulib API, which
says "we'll try to avoid the race if we can". So far, GNU applications needing
renameat2-like functionality have all fallen into the Coreutils camp.
I would like *coretuils* itself to make the decision
in their sources, with full disclosure,
Coreutils already does that. Coreutils uses Gnulib, which is a source-code
library. Coreutils tarballs contain a copy of the source code that embody this
decision and fully disclose it. And if Glibc added an API that supported
Coreutils-like functionality here, programs using this new API would also be
making the decision with full disclosure. So we should be OK here.
