Date: Fri, 4 Jan 2013 12:56:56 -0800 From: Oleg Moskalenko <oleg.moskalenko@citrix.com> To: 'Robert Watson' <rwatson@FreeBSD.org>, Mateusz Guzik <mjguzik@gmail.com> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, David Xu <davidxu@FreeBSD.org> Subject: RE: svn commit: r245036 - head/sys/kern Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA8FA98F2@SJCPMAILBOX01.citrite.net> In-Reply-To: <alpine.BSF.2.00.1301042036440.61411@fledge.watson.org> References: <201301041111.r04BBDjZ013380@svn.freebsd.org> <20130104113354.GB26239@dft-labs.eu> <alpine.BSF.2.00.1301042036440.61411@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > > I think it would be better to teach strlcpy to zero-pad as well. >=20 > I'd rather we created new functions with new names that add the non-porta= ble > zeroing behaviour -- perhaps strlpcpy() and strnpcpy(), or something equa= lly > incomprehensible. This semantic may actually trigger bugs in code that i= s > correct (albeit badly written) using strncpy() and strlcpy() in a way tha= t never fully > fills the buffer (due to some external invariant) and has an incorrect bo= unds > check -- and potentially trigger performance problems when target buffers= are > much larger than the copied data. >=20 > Robert > _______________________________________________ Robert is right - this is not a good idea to rely on a non-standard "smart"= behavior of basic functions. If the developer wants to code it "securely",= he/she always can use his own wrappers around the strncpy() etc. Any inher= ent built-in behavior that is not "standard" is affecting future maintenanc= e of the code. =20 Oleg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?031222CBCF33214AB2EB4ABA279428A3012CA8FA98F2>