[PATCH] misc: Add mkostempat (BZ 19866)

[Adhemerval Zanella Netto]

On 22/06/26 15:41, Paul Eggert wrote:
> On 2026-06-22 09:35, Adhemerval Zanella Netto wrote:
>>
>>
>> On 22/06/26 13:22, Paul Eggert wrote:
>>> On 2026-06-22 06:57, Adhemerval Zanella Netto wrote:
>>>> I am working a v2 based on this design, I am still not convinced on adding
>>>> the callback-like interface to allow openat2.
>>>
>>> The case for the more-complicated interface would be stronger if we had actual use cases for it. We already have real use cases based on the callback-like approach in Gnulib. What are the real uses cases for the more-complicated interface, use cases that the callback-like approach can't do?
>>
>> I am trying to focus on the original bug report issue, instead of trying
>> to come up with a more complicated interface that required more setup and
>> care to be used (and the callback still has the very versioning issues, as
>> nftw/fts shows).
> 
> Sounds like we're in disagreement then, about how to address the original bug report. Let me summarize where I think the callback-oriented approach is better.
> 
> First, a callback-oriented API is simpler (fewer arguments and easier to explain) than the many-argument API. We can cut the callback API down to three arguments: char *template, the function, and void *function-arg.
> 
> Second, there aren't versioning issues in the callback-oriented API. nftw/fts's versioning issues don't apply here, because the callback function accepts only char * and void *: the char * is a mutable string and that won't change, and the void * is up to the application. There are no tricky types like off_t or time_t or struct stat.
> 
> Third. the callback-oriented approach is more general, and solves real problems (e.g., GNU 'cp' creating symlinks) that the more-complicated API does not address.
> 
> Fourth, although I concede that the callback approach does mean callers must define a callback function, that's a relatively minor drawback: glibc already has multiple APIs that already use callbacks, developers are already well-acquainted with the idea of callbacks, and these callback functions will be relatively simple.

Fair enough, the nftw/fts's versioning issues indeed don't apply here (sorry
for the confusion).

Checking gnulib lib/tempname.h, think we can bake the dirfd argument with the 
cost of boilerplate:

  struct my_ctx { int dirfd; int oflags; mode_t mode; };
  static int my_create (char *name, void *arg)
  {
    struct my_ctx *c = arg;
    return openat (c->dirfd, name,
                   c->oflags | O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC, c->mode);
  }
  struct my_ctx c = { dirfd, oflags, mode };
  try_tempname (tmpl, suffixlen, &c, my_create);

I am not a fan of these typeless void * arguments, but I live with it.

But there are still the issue of the safe default (forget O_EXCL (loses atomicity)
or O_CLOEXEC (fd leak)). And these are still footguns that the non-callback avoids,
and I don't have a easy answer for the call without adding some extra checks
(fnctl after the fd creation).