From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5133 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Daniel_Cegie=C5=82ka?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Mon, 19 May 2014 18:30:21 +0200 Message-ID: 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=UTF-8 X-Trace: ger.gmane.org 1400517063 20059 80.91.229.3 (19 May 2014 16:31:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2014 16:31:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5138-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 19 18:30:55 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 1WmQSk-0003cC-JA for gllmg-musl@plane.gmane.org; Mon, 19 May 2014 18:30:54 +0200 Original-Received: (qmail 27860 invoked by uid 550); 19 May 2014 16:30:53 -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 27852 invoked from network); 19 May 2014 16:30:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=1ZWfPHtuldtxRSih3dmHuG8SR0Mrth3entEaFf8WJ4w=; b=xyxXMme7UC8wT7/5DLMEt610pNv9hcwOVUMKBBLgfA5NsKVhFtEYGGxjmC02D+MF4R kCOYxG8UBw8tVAxhcPUqTbbyftKK4TTv0nxt2o9iS4UWMDtcw0QoVNqY22N98IIAB/4e O2f5Pv8djk3ybLC+PsOLoJ5tGRMV05ajrqS7HaGs9Kpl0DwOndJOEyiNHCRtYRNTwkKT z9fjvor3AsiZHhT0OxyODAYNVAdLTjfIcyG7EIOpTjuoFOS6KalKhvAIdZ+dtVP2lF+c v6Op1Psa0ag0anYcJniWVlGy1uUnnptrq5ISkCg5hK6POWed8wDJxrh96jdphBjhh2Pg lZ0g== X-Received: by 10.140.19.68 with SMTP id 62mr49105576qgg.55.1400517041905; Mon, 19 May 2014 09:30:41 -0700 (PDT) In-Reply-To: <20140519161654.GO507@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5133 Archived-At: 2014-05-19 18:16 GMT+02:00 Rich Felker : >> _Noreturn void abort (void); >> int atexit (void (*) (void)); >> diff -urN musl.orig/src/stdlib/reallocarray.c musl/src/stdlib/reallocarray.c >> --- musl.orig/src/stdlib/reallocarray.c Thu Jan 1 00:00:00 1970 >> +++ musl/src/stdlib/reallocarray.c Thu May 8 09:06:30 2014 >> @@ -0,0 +1,17 @@ >> +#include >> +#include >> +#include >> + >> +/* this is sqrt(SIZE_MAX+1), as s1*s2 <= SIZE_MAX >> + * if both s1 < MUL_NO_OVERFLOW and s2 < MUL_NO_OVERFLOW */ >> +#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. It was a quick fix only from malloc.c from openbsd :) I use a lot of programs from openbsd and I had problems with the compilation. > > Also, is there a reason you're using SSIZE_MAX? SIZE_MAX should work > just as well here, but functionally it makes no difference. yes, I should correct it: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/reallocarray.c?rev=1.1;content-type=text%2Fplain Thanks, Daniel > Rich