Better check the return value of asprintf being -1.

You are using mkstemps in the program, but here and in mapfile mktemps got added instead.

template

mkstemps?

I don't see mkstemp being discussed anywhere in this man page.

it is small nit, but it would be good to have empty line after variable declarations. Same for line 119.

Hi, thanks for putting this together. In general, this looks pretty good. I know there are a number of comments here, but some of these come from being a side effect of adding a new symbol to libc and the headers which can be a bit trickier as we need to make sure we do things for versioning, symbols, etc.

I'm not sure it makes sense to add a new mktemps function as it's just used as an implementation detail of mkdtemps that you added and it has the classic TOCTTOU problem with mktemp.
For new manual pages you need to update the Makefile in man/man3c/Makefile to add the new symbols as links to the existing pages
When the above is done, you'll probably get a pacakaging failure as we'll need to make sure that the new manual page symlinks are shipped. If you look at past examples of adding symbols to libc that should hopefully make it a bit clearer
For more information on the symbol versioning, please see usr/lib/README.mapfiles
If we do add new symbols to libc, we should probably look at adding them to the symbol visibility tests. That's something I can help with once we've reached a conclusion on the rest.

If I can help out with any of these or if I can better clarify some of these things that you've done, please let me know. Again, thanks for putting this together and looking to contribute!

It appears the gnu option for this is --suffix. Is it worth being compatible with them in addition to the short option?

You don't need to check both of these, for what it's worth.

It looks like this is a new function that we're adding to libc. I don't see it defined elsewhere, is that correct? There also doesn't seem to be a version of this in other operating systems that I can track down.

I don't think it's correct to put this in this section of the header file unfortunately. It needs to be in as section as the OpenBSD compat symbols. aka if !defined(_STRICT_SYMBOLS).

See the same thing as the above.

Is there a reason that this doesn't just call libc_mktemps directly? I understand the desire to have an mktemp, but one gotcha with mktemps is that it has a classic time of check to time of use that at least the mkstemp* family doesn't. I'm not sure whether or not it really makes sense to have a new function for the latter.

When adding new library symbols they cannot go into an existing symbol version. They need to go into a new version.

Please see the above.

The mkdtemps function needs to be added to this section.

We need to update the ERRROS section to indicate which ones that mkdtemps can return. Also, we need to double check what the error behavior is on a negative or invalid suffix length.

Th mkdtemps function needs to be added here. Note it is not a standard interface, so we'll need to think about whether or not it makes sense.

The return values section needs to be updated to refer to the new function.

Is the same thing about no errors are defined true for mktemps? What about things like a negative suffix length?

The new function isn't actually part of a standard. We should probably figure out whether or not we really want to make it part of a public interface or not. My main concern with making this public is if other groups end up doing something divergent we'll be in a compatibility quagmire.

The effort for me to convert this to use getopt_long would be minimal so I'd think adding --suffix for gnu compatibility is worthwhile.

This is new, correct. I believe after addressing your other concerns, there is no need for mktemps at all.

mkdtemp called mktemp but calling libc_mktemps directly here removes the need for mktemps.

I don't think we want to cast this to an int. That'll effectively truncate a size_t down to an int (so a potentially 64-bit value to a 32-bit one). I would probably cast up slen to a size_t in the comparison.

You should update the date for your change.

Perhaps note here that in addition to -s suffix, we also support the long form --suffix?

You should probably put suffix in markup here, I think you want \fIsuffix\fR, to indicate that it's referring to the actual argument.

Another spot where we'll need to update the date.