Date: Mon, 5 May 2014 22:52:21 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Andrey Chernov <ache@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Pedro F. Giffuni" <pfg@FreeBSD.org>, src-committers@freebsd.org Subject: Re: svn commit: r265367 - head/lib/libc/regex Message-ID: <D02BC3E0-0D7E-468D-BFE2-1FBB7AB8F0AC@FreeBSD.org> In-Reply-To: <53680532.7050605@freebsd.org> References: <201405051641.s45GfFje086423@svn.freebsd.org> <5367CD77.40909@freebsd.org> <B11B5B25-8E05-4225-93D5-3A607332F19A@FreeBSD.org> <53680532.7050605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 May 2014, at 22:40, Andrey Chernov <ache@freebsd.org> wrote: > On 05.05.2014 22:28, David Chisnall wrote: >> On 5 May 2014, at 18:42, Andrey Chernov <ache@freebsd.org> wrote: >> >>> Please don't commit OpenBSD errors. Now you mix calloc() with the >>> realloc() for the same variable later which makes calloc() zeroing >>> pointless and waste of CPU. >> >> The purpose of calloc() here is not (primarily) to get the zero'd size, it's to get the overflow-checking behaviour for calloc. > > It is better to avoid using undocumented intrinsic knowledge of standard > function particular implementation, this is unportable at least and hard > to understand too. calloc() is required to return either NULL or a valid pointer to the requested amount of memory. An implementation that does not correctly check for overflow is buggy and will be regarded as a security hole (see: http://cert.uni-stuttgart.de/ticker/advisories/calloc.html), but fortunately these were all fixed by around 2004. This is not relying on undocumented intrinsic knowledge, this is relying on the standard library doing what is required of it. There is a reason why secure coding standards have, for over a decade, said to prefer calloc() over malloc() unless profiling shows that calloc() is a bottleneck: it means that only one person needs to get the overflow checking right in one place, rather than everyone getting it right everywhere. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D02BC3E0-0D7E-468D-BFE2-1FBB7AB8F0AC>