This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]