[PATCH] misc: Add mkostempat (BZ 19866)

[Adhemerval Zanella Netto]

On 23/06/26 16:09, Paul Eggert wrote:
> On 2026-06-23 10:01, Mark Wielaard wrote:
>> int
>> mkostempat (int dirfd,
>>             int (*tryfunc) (int, char**, void *), void *args,
>>             int len, char **name)
> 
> Yes, I was thinking along those lines, though 'len' isn't needed (it can be deduced from the template). Even 'dirfd' can be dispensed with if we want to simplify the API further, as the caller can pass it as part of the args.
> 
> This is the sort of thing Gnulib is doing already, though the API needs to be rationalized (a better name for the function, for example). (If the function's name ends in "at", it should keep 'dirfd' as an arg, though really the idea is more general than an "at" function.)
> 
> All the existing mk*t*mp* functions can be implemented atop this more-general idea.

So I am working on a function with prototype: 

      int mkostempfn (const char *prefix, unsigned int n_random,
                      const char *suffix, int (*tryfunc) (char *, void *),
                      void *args, char **nameout);

Where the function creates temporary files in the form of
<prefix><n_random characteres><suffix>.  I tend to agree with Florian that
mutate input is a footgun that we should avoid.

The dirfd could be implemented as:

struct create_args
{
  int dirfd;
  mode_t mode;
};

static int
create_at (char *name, void *closure)
{
  struct create_args *a = closure;
  return openat (a->dirfd, name,
                 O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC, a->mode);
}

int
open_temp_at (int dirfd, char **nameout)
{
  
  return mkostempfn ("tmp-",
                     0,
                     NULL,
		     &(struct create_args) { dirfd, 0600 };
                     create_at,
                     &a,
                     nameout);
}

> 
>> Or maybe we can allow NULL for the callback, in which case it would be
>> the "standard" name/mode/len?

A standard callback would required to tie to some specific semantic (using
open syscall, which would need to accept full path). It should be doable,
although I am not sure if it would be an improvement to the interface.