[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 May 2014 18:32:37 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: thoughts on reallocarray, explicit_bzero?
* Rich Felker <dalias@...c.org> [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..
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
