Date: Tue, 06 May 2014 02:00:22 +0400 From: Andrey Chernov <ache@freebsd.org> To: David Chisnall <theraven@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: <536809F6.8000302@freebsd.org> In-Reply-To: <D02BC3E0-0D7E-468D-BFE2-1FBB7AB8F0AC@FreeBSD.org> References: <201405051641.s45GfFje086423@svn.freebsd.org> <5367CD77.40909@freebsd.org> <B11B5B25-8E05-4225-93D5-3A607332F19A@FreeBSD.org> <53680532.7050605@freebsd.org> <D02BC3E0-0D7E-468D-BFE2-1FBB7AB8F0AC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06.05.2014 1:52, David Chisnall wrote: > 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. It was unclear what type of ckecking you mean initially and confirm my statement that such code is hard to understand. Even if it is for arithmetic overflow, it is still semantically incorrect, see my other answer. Main purpose of calloc is to zero memory, not to check its argument, so its argument checking is side effect. It should be implemented by the caller (as I already answer) and not by the price of zeroing. -- http://ache.vniz.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?536809F6.8000302>