This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C11 bounds checking interfaces in glibc?
On Wed, 15 Feb 2012, Andi Kleen wrote:
> On Wed, Feb 15, 2012 at 09:11:18PM +0000, Joseph S. Myers wrote:
> > I don't think there are any plans; see
> > <http://sourceware.org/ml/libc-alpha/2011-12/msg00066.html> for what I
> > said about them and
> > <http://sourceware.org/ml/libc-alpha/2011-12/msg00064.html> for what
> > Roland said. In essence, they are rather a mess and *most* of them (other
> > than the reentrant functions) probably are not desirable for use in new
> > code - but there are probably uses for them for compiling some existing
> > bodies of code that have been retrofitted with them.
>
> So how do we get string functions with overflow checking instead?
I don't oppose adding these functions somewhere (though I'm not sure
whether libc or another library, whether within the main glibc sources or
an add-on - my guess is libc itself unless a clean approach for doing
otherwise occurs to people). It's unfortunate there isn't any standard
for managed strings that do dynamic memory allocation, as that's what
would be better for most new programs....
> Is the general recommendation everyone has to use libbsd now?
>
> It's mainly of me being sick of writing
>
> #define strlcpy(d,s,l) snprintf(d,l,"%s",s), d
>
> everywhere.
As I said in my message I referred to, personally I'd have allowed in
strlcpy and strlcat long ago (given a properly assigned patch including
documentation, testcases, symbol versions etc.). They're not bad in the
way that "gets" is bad, I think they're no worse than snprintf and the
style of coding they support (avoid truncation but also pass buffer sizes
as a safety matter) is reasonable enough even if managed strings
(including buffer sizes in a structure along with the string pointer so
they never get out of sync) are safer. But some people oppose adding
them, lots of people haven't indicated their views and positions on these
functions have become rather entrenched....
--
Joseph S. Myers
joseph@codesourcery.com