[PATCH] misc: Add mkostempat (BZ 19866)

[Adhemerval Zanella Netto]

On 24/06/26 07:11, Mark Wielaard wrote:
> Hi,
> 
> On Tue, Jun 23, 2026 at 04:28:46PM -0300, Adhemerval Zanella Netto wrote:
>> 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.
> 
> So it looks like we all have slightly different goals and priorities.
> And also want a generic function that allows users to do everything
> the existing mk*stemp* functions do, plus more. And want an interface
> as clean and minimal as possible so users cannot use the interface in
> a way to causes them to trip over footguns. Unfortunately we don't
> agree on what the worst footguns are either.
> 
> For me the most important thing is having a simple function to create
> a temporary file in a specific directory, so you can get rid of any
> path based calls (which are a toctou footgun). So I don't like an
> interface where the dirfd argument needs to be passed around through a
> callback closure and I need to select or write a specific
> callback. All the other arguments however are fine to hide that way
> because all I really need is giving a n dirfd and getting an file
> descriptor and name back. I don't care about the name really, and
> would trust glibc to pick the right amount of randomness, mode and
> flags.
> 
> But if you don't believe the path based way of invoking the mk*stemp*
> functions is the biggest footgun then the name/template becomes more
> important as argument not to get wrong.
> 
> I am wondering if we should have both a super generic mkostempfn and a
> specific mkostempat function (implemented on top of the mkostemfn).
Just to be clear, I do prefer the original one:

  int mkostempat (int dirfd,             /* as other *at functions.  */
                  const char *prefix,    /* maybe a relative or absolute.  */
                  const char *suffix,    /* no '/' allowed; may be "" */
                  unsigned int n_random, /* entropy chars, 0 -> default 6 */
                  int oflags,            /* extra O_* OR'd into the create */
                  mode_t mode,           /* e.g. 0600 */
                  char *namebuf,         /* output, or NULL */
                  size_t namebuf_size);  /* bound; ERANGE/ENAMETOOLONG on overflow */

Where namebuf_size can be inferred by strlen(prefix)+strlen(suffix)+n_random.
As I said, it fixes a lot of footguns from the mkstemp* functions, without
re-introducing more or adding error-prone interfaces like typeless callback
(yes, we are coding in C but we can also do better and avoid repeating historic
mistakes).

I am exploring this callback interface more to check what kind of shortcomings
we might have; and I am not sure the gnulib example interfaces are really
a fit for glibc.

In fact, after this discussion I am not even sure if glibc is indeed the
correct place for a new mkstem* function. Any pick choice in this discussions
will have some shortcoming.