[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