add mkstemps

Howland Craig D (Craig) howland@LGSInnovations.com
Tue Jun 30 21:00:00 GMT 2009


An alternate thought:
Practically, size_t versus int for the suffix length makes no
difference at all.  That is, both int and size_t can easily have
numbers that are far too big compared to FILENAME_MAX (or any of the
other variations for max path lengths) to actually work.  If size_t
were used, passing a negative integer would come out to be too big and
result in an error.
 
Therefore, why not declare it to be the "proper" size_t from the start?
It would work with good code that uses the extant int, yet be defined
in the proper manner.  Code that passes bad values for the length
will blow up in slightly different ways for size_t vs. int, but all
good values ought to behave the same.  (It seems very unlikely that
any 16-bit int systems would allow path lengths >32k.)
 
Thinking of this, a potential weakness in the new code is that it
does not sanity-check the given suffix length.  (Unless perhaps I've
missed a touchup, as one of the gmane comments that Eric made implies
that some kind of negative length check was added.)
 
Secondly, the addition probably should be in unistd.h.  stdlib.h is
properly fully standardized from ISO and POSIX.  We should avoid
"polluting" it with non-standard items (not that it isn't already).
If it needed to be moved later if it ever became standard, then move it
later.  (Or perhaps now is a good time to introduce a stdlibext.h
file, which is one of the things that I've been thinking about as a
possible mechanism for cleaning up the system header files.)
 
Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Jeff Johnston
Sent: Monday, June 29, 2009 6:37 PM
To: Eric Blake
Cc: newlib@sources.redhat.com
Subject: Re: add mkstemps

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.



More information about the Newlib mailing list