[PATCH] misc: Add mkostempat (BZ 19866)

[Adhemerval Zanella Netto]

On 18/06/26 18:06, Paul Eggert wrote:
> On 2026-06-18 12:55, Adhemerval Zanella Netto wrote:
> 
>>    * openat2 as generic ABI with its extendable open_how is not a good fit:
>>      it would require additional versions each time we extend it.
> 
> Do you mean multiple versions like the _TIME_BITS mess? But openat2 shouldn't need additional versions for that, if it increases the size of its struct layout. And I'm not seeing why a revised mkostempat would need it either. So I'm not quite following here.

Kinda, but more in the sense of the openat2 note we added on the manual:

  @strong{Portability note:} In the future, additional fields can be added
  to @code{struct open_how}, so that the size of this data type increases.
  Do not use it in places where this matters, such as structure fields in
  installed header files, where such a change could affect the application
  binary interface (ABI).

We can add similar note for a mkstemp-like interface, and do not handle the
symbol versioning issue at all.

> 
>>    * We will need to add a fallback for older kernels and Hurd; and I *really*
>>      do not want to pull the gnulib implementation. Mainly because kernel
>>      fallback has bitten us in the past and it is a pain to maintain.
> 
> That's fine, just return EOPNOTSUPP for flags you can't implement.

Maybe, but these are not ideal for an generic interface. We does not really
return EOPNOTSUPP for a lot of interface, and we really try to avoid it
when possible (like fchmodat).  And handling EOPNOTSUPP for the cases where
users will require a fallback can be really troublesome (like the
posix_fallocate issues we had along the years).

> 
>> There is also the question of each openat2 flag would be really a gain
>> for this interface.
> 
> I suspect the designers of mkstemp had similar thoughts, many years ago: "Who needs all those flags? Let's just keep the interface simple. Nobody will want to use those flags." That was a mistake.
> 
> 
> Come to think of it, why not address this issue with a callback instead? That is, replace the dirfd, oflags and mode argument with a closure, namely, a function f and a void *arg. mkostemp calls f (name, arg) to create the file. Then the caller can use whatever fancy flags they like.

Well, we will need to come up with a semantic what we will be safe in the
callback interface.  And callback has other complications when mixed with
different runtime (like this issue with qsort [1]). I am not really sure
if this would really simplify things.

That's why I posed the question of what kind of openat2 flags would be
good to support.  These can guide if extending these interface even more
would really pay off.

At least this proposal does fix some historical pitfalls of current mkstemp 
family, and provide the *at extensions from the original bug report.

> 
> sysdeps/posix/tempname's try_tempname function, which is currently compiled only for Gnulib, already does this. So why not do something along those lines? It would avoid the ABI and fallback issues that you mention. And Gnulib provides existing practice for this idea.
> 

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32058