Re: add mkstemps

[Jeff Johnston <jjohnstn at redhat dot com>]

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.