Re: [PATCH] misc: Add mkostempat (BZ 19866)

Hi Paul,

On Thu, Jun 25, 2026 at 05:45:44PM -0700, Paul Eggert wrote:
> On 2026-06-25 14:59, Mark Wielaard wrote:
> >If not, can we have a simple mkstempat one that just adds the dirfd
> >argument, but doesn't try to fix any other issue?
> 
> We could, but there is always one more feature that people want. For
> example, if/when Linux adds O_CREAT|O_DIRECTORY support to openat2,
> or a mkdirat2 API (or whatever), we'll need yet another function to
> make this new kernel facility available in the mkdtemp family.

I think there is a difference between what people might want in the
future and features that are needed because the original design of a
function didn't allow a safe way to implement them. We can speculate
about future ideas/apis, but we do know that not defaulting to
O_CLOEXEC and only providing a path based api creates race conditions.

> In the end it's simpler to have a function with a callback.
> 
> Gnulib supports historical or standardized variants like
> gen_register_open_temp, gen_tempname_len, mkdtemp, mkostemp,
> mkostemps, mkstemp, mkstemps, and tmpfile. What a mess, right! But
> once we have a callback-oriented function we don't need to add more
> to the mess. And in Gnulib these variants are all implemented atop a
> callback-oriented function anyway.

I am not saying to not use a callback-oriented function to implement a
mkstempat like function. It might simplify the implementation of all
variants. But I am not convinced that only providing an (somewhat
abstract) function with a callback/closure is the most user friendly
way of providing this functionality. If you do decide to make such an
function public then also provide a convenience function that provides
the mkstempat functionality without the user having to write their own
callback function and argument data struct.

Cheers,

Mark