From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5134 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Mon, 19 May 2014 18:32:37 +0200 Message-ID: <20140519163236.GZ12324@port70.net> References: <20140519153130.GA519@muslin> <20140519161654.GO507@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1400517180 21714 80.91.229.3 (19 May 2014 16:33:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2014 16:33:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5139-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 19 18:32:53 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WmQUb-0007MY-Go for gllmg-musl@plane.gmane.org; Mon, 19 May 2014 18:32:49 +0200 Original-Received: (qmail 29865 invoked by uid 550); 19 May 2014 16:32:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29857 invoked from network); 19 May 2014 16:32:48 -0000 Content-Disposition: inline In-Reply-To: <20140519161654.GO507@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5134 Archived-At: * Rich Felker [2014-05-19 12:16:54 -0400]: > On Mon, May 19, 2014 at 05:44:59PM +0200, Daniel Cegie??ka wrote: > > +#define MUL_NO_OVERFLOW (1UL << (sizeof(size_t) * 4)) > > + > > +void *reallocarray(void *optr, size_t nmemb, size_t size) > > +{ > > + if ((nmemb >= MUL_NO_OVERFLOW || size >= MUL_NO_OVERFLOW) && > > + nmemb > 0 && SSIZE_MAX / nmemb < size) { > > + errno = ENOMEM; > > + return NULL; > > + } > > + return realloc(optr, size * nmemb); > > +} > > While it's a bit ugly, if your goal is efficiency, it makes a lot more > sense to special-case 32-bit systems and do a 32x32 -> 64 multiply. > This makes it so you don't need division code or any extra branches. > And for 64-bit systems, either nmemb or size being >32bit would be a > pathological corner case (and very slow already anyway), so your check > is efficient. > > Also, is there a reason you're using SSIZE_MAX? SIZE_MAX should work > just as well here, but functionally it makes no difference. i think this ugly code is from openbsd they like to use such obfuscated checks for no apparent reason..