All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@gmail.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
Date: Sun, 21 Aug 2005 22:47:13 +0300	[thread overview]
Message-ID: <84144f0205082112477979b053@mail.gmail.com> (raw)
In-Reply-To: <20050820193237.GG3615@stusta.de>

On 8/20/05, Adrian Bunk <bunk@stusta.de> wrote:
> This change could (at least in theory) allow a compiler better
> optimization (especially in the n=1 case).
> 
> The practical effect seems to be nearly zero:
>     text           data     bss      dec            hex filename
> 25617207        5850138 1827016 33294361        1fc0819 vmlinux-old
> 25617191        5850138 1827016 33294345        1fc0809 vmlinux-patched
> 
> Is there any reason against this patch?

Looks ok to me.

On 8/20/05, Adrian Bunk <bunk@stusta.de> wrote:
>  static inline void *kcalloc(size_t n, size_t size, unsigned int __nocast flags)
>  {
> -       if (n != 0 && size > INT_MAX / n)
> +       if (n != 0 && size > ULONG_MAX / n)

You'll probably get even better code if you change the above to:

    if (size != 0 && n > ULONG_MAX / size)

Reason being that size is virtually always a constant so the compiler
can evaluate the division at compile-time.

                                  Pekka

  reply	other threads:[~2005-08-21 21:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-20 19:32 [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX Adrian Bunk
2005-08-21 19:47 ` Pekka Enberg [this message]
2005-08-21 19:54   ` Adrian Bunk
2005-08-21 20:12     ` Pekka Enberg
2005-08-25 16:01       ` Adrian Bunk
  -- strict thread matches above, loose matches on Subject: below --
2006-01-28 22:30 Adrian Bunk

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=84144f0205082112477979b053@mail.gmail.com \
    --to=penberg@gmail.com \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.