public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
Cc: libc-hacker@sources.redhat.com
Subject: [PATCH] optimize calloc
Date: Sat, 03 Aug 2002 05:03:00 -0000	[thread overview]
Message-ID: <20020803140349.N20867@sunsite.ms.mff.cuni.cz> (raw)
In-Reply-To: <20020802121321.25638.qmail@md.dent.med.uni-muenchen.de>; from wmglo@dent.med.uni-muenchen.de on Fri, Aug 02, 2002 at 12:13:21PM -0000

On Fri, Aug 02, 2002 at 12:13:21PM -0000, Wolfram Gloger wrote:
> > 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?

Ok, here is the patch:

2002-08-03  Jakub Jelinek  <jakub@redhat.com>

	* malloc/malloc.c (public_cALLOc): Only divide if one of arguments
	is bigger than 65535.

--- libc/malloc/malloc.c.jj	2002-08-02 11:47:41.000000000 +0200
+++ libc/malloc/malloc.c	2002-08-03 13:47:50.000000000 +0200
@@ -488,6 +488,9 @@ Void_t *(*__morecore)(ptrdiff_t) = __def
 #endif /* _LIBC */
 #endif /* USE_DL_PREFIX */
 
+#ifndef _LIBC
+#define __builtin_expect(expr, val)	(expr)
+#endif
 
 /*
   HAVE_MEMCPY should be defined if you are not otherwise using
@@ -3466,9 +3469,11 @@ public_cALLOc(size_t n, size_t elem_size
 
   /* size_t is unsigned so the behavior on overflow is defined.  */
   bytes = n * elem_size;
-  if (bytes / elem_size != n) {
-    MALLOC_FAILURE_ACTION;
-    return 0;
+  if (__builtin_expect ((n | elem_size) >= 65536, 0)) {
+    if (bytes / elem_size != n) {
+      MALLOC_FAILURE_ACTION;
+      return 0;
+    }
   }
 
   if (hook != NULL) {


	Jakub

  reply	other threads:[~2002-08-03 12:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-01 15:46 [PATCH] xdr_array and calloc security fix Jakub Jelinek
2002-08-02  0:20 ` Ulrich Drepper
2002-08-02  2:29 ` Wolfram Gloger
2002-08-02  2:43   ` Ulrich Drepper
2002-08-02  2:50     ` Ulrich Drepper
2002-08-02  2:56       ` Jakub Jelinek
2002-08-02  4:07         ` Andreas Schwab
2002-08-02  4:46           ` Jakub Jelinek
2002-08-02  4:57             ` Wolfram Gloger
2002-08-02  5:05               ` Jakub Jelinek
2002-08-02  5:13                 ` Wolfram Gloger
2002-08-03  5:03                   ` Jakub Jelinek [this message]
2002-08-03 12:02                     ` [PATCH] optimize calloc Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020803140349.N20867@sunsite.ms.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=libc-hacker@sources.redhat.com \
    --cc=wmglo@dent.med.uni-muenchen.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).