From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-5366-listarch-libc-hacker=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 2894 invoked by alias); 2 Aug 2002 12:13:31 -0000
Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-hacker-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sources.redhat.com>
List-Help: <mailto:libc-hacker-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: libc-hacker-owner@sources.redhat.com
Received: (qmail 2840 invoked from network); 2 Aug 2002 12:13:23 -0000
Received: from unknown (HELO md.dent.med.uni-muenchen.de) (138.245.179.2)
  by sources.redhat.com with SMTP; 2 Aug 2002 12:13:23 -0000
Received: (qmail 25639 invoked by uid 211); 2 Aug 2002 12:13:21 -0000
Date: Fri, 02 Aug 2002 05:13:00 -0000
Message-ID: <20020802121321.25638.qmail@md.dent.med.uni-muenchen.de>
From: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
To: jakub@redhat.com
CC: libc-hacker@sources.redhat.com
In-reply-to: <20020802140412.E20867@sunsite.ms.mff.cuni.cz> (message from
	Jakub Jelinek on Fri, 2 Aug 2002 14:04:12 +0200)
Subject: Re: [PATCH] xdr_array and calloc security fix
References: <20020802004635.Y20867@sunsite.ms.mff.cuni.cz> <20020802092945.24679.qmail@md.dent.med.uni-muenchen.de> <3D4A5446.5030204@redhat.com> <3D4A55F0.5020007@redhat.com> <20020802115506.C20867@sunsite.ms.mff.cuni.cz> <jeit2twmba.fsf@sykes.suse.de> <20020802134512.D20867@sunsite.ms.mff.cuni.cz> <20020802115729.25576.qmail@md.dent.med.uni-muenchen.de> <20020802140412.E20867@sunsite.ms.mff.cuni.cz>
X-SW-Source: 2002-08/txt/msg00021.txt.bz2

> Why not 2^32? size_t is unsigned.

Yes, however malloc can only handle chunks of a little less than 2^31
currently, so the _int_malloc later will fail anyway...  But that is
ok, having a power of two as the compared value wins against this
micro-optimisation:

> So you mean something like:
>   bytes = n * elem_size;
>   if (__builtin_expect ((a | b) >= 65536, 0)) {
>     if (bytes / elem_size != n) {
>       MALLOC_FAILURE_ACTION;
>       return 0;
>     }
>   }

Hey, nice, avoids the second comparision and ||.  Looks like we have a
winner?

Regards,
Wolfram.