[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mkstemps

From: Eric Blake
Subject: Re: mkstemps
Date: Mon, 29 Jun 2009 15:00:42 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Jim Meyering <jim <at> meyering.net> writes:

> I read this: http://docs.sun.com/app/docs/doc/819-2243/mkstemps-3c?a=view
>       int mkstemps(char *template, int slen);
>       ...
>     Description
>       ...
>       The mkstemps() function behaves the same as mkstemp(), except it
>       permits a suffix to exist in the template. The template should
>       be of the form /tmp/tmpXXXXXXsuffix. The slen parameter specifies
>       the length of the suffix string.
> That looks useful, but why use a signed type for that "slen" parameter?

Solaris did it because they were copying BSD, which also did that.  And when 
git recently added git_mkstemps, they kept int.  But I agree that it is stupid; 
and in my first attempt at a newlib implementation, I indeed had a bug where 
the user could pass a negative value and thus cause the library to write memory 
beyond the template bounds.  I guess it would be nice to audit the BSD and 
OpenSolaris implementations to see if they have out-of-bounds bugs.

> I'd suggest using size_t if you provide the function, and consider
> replacing the above interface.
> Then, if it's ever standardized, perhaps they'll get it right.

Maybe the thing to do is first probe the glibc waters, and see how likely 
mkstemps is to be accepted there (with either a broken signature or your 
preferred size_t signature).  After all, our gen_tempname function is borrowed 
from glibc.  I hate writing glibc bug reports for requesting new interfaces 
(based on the flaming I received last time I attempted that, with a request for 
verror), but I guess I can take the heat and do that first.

Eric Blake

reply via email to

[Prev in Thread] Current Thread [Next in Thread]