add mkstemps

[Jeff Johnston]

Eric Blake wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
>
>   
>> The ability to have an arbitrary file suffix on a temporary file is quite
>> useful for programs that react to a file's extension; in fact, git wants
>> to use mk[s]temps when available, even though no standards bodies have
>> adopted it yet.  According to google, mkstemps is available on several
>> systems (sometimes by the more confusing name mktemps), but there is no
>> consistency on whether it should be in <stdlib.h> or <unistd.h>.  I went
>> with <stdlib.h>, since that is where POSIX puts mkstemp.  This also fixes
>> the documentation (mktemp is NOT in <stdio.h>), but does not move the
>> files to a more appropriate subdirectory.
>>
>> OK to apply?
>>     
>
> Jim Meyering raised a good point[1] - we shouldn't have to repeat the stupidity 
> of earlier implementations in using a signed int for a length, when size_t is 
> more appropriate.  If enough implementations exist with an appropriate 
> parameter type, then if this function is considered for future standardization, 
> the early implementers will then have to upgrade to use the saner prototype.
>
> So, do we want to provide:
>
> int mkstemps (char *, size_t)
>
> instead of following BSD and Solaris tradition?
>
> [1] http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/17994/focus=17995
>
>   
IMO, no.  Until an actual standard defines it,  then one should stick 
with the expected documented legacy prototype.  This is not a unique 
situation where a function was not originally designed as well as it 
could be.

-- Jeff J.