From: Matt Mackall <mpm@selenic.com>
To: Christophe Saout <christophe@saout.de>
Cc: Andreas Gruenbacher <agruen@suse.de>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] lib/sort: Heapsort implementation of sort()
Date: Tue, 1 Mar 2005 12:12:41 -0800 [thread overview]
Message-ID: <20050301201241.GM3120@waste.org> (raw)
In-Reply-To: <1109703983.16139.16.camel@leto.cs.pocnet.net>
On Tue, Mar 01, 2005 at 08:06:22PM +0100, Christophe Saout wrote:
> Am Sonntag, den 27.02.2005, 13:25 -0800 schrieb Matt Mackall:
>
> > Which kernel? There was an off-by-one for odd array sizes in the
> > original posted version that was quickly spotted:
> >
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/broken-out/sort-fix.patch
> >
> > I've since tested all sizes 1 - 1000 with 100 random arrays each, so
> > I'm fairly confident it's now fixed.
>
> - int i = (num/2 - 1) * size, n = num * size, c, r;
> + int i = (num/2) * size, n = num * size, c, r;
>
> What's probably meant is: ((num - 1)/2) * size
>
> `i' must cover half of the array or a little bit more (not less, in case
> of odd numbers). `i' (before my patch) is the highest address to start
> with, so that's why it should be ((num + 1)/2 - 1) * size or simpler:
> ((num - 1)/2) * size
Argh. Yes, you're right. This probably deserves a comment since it's
been gotten wrong twice. I'll add something..
> Anyway, I was wondering, is there a specific reason you are not using
> size_t for the offset variables? size is a size_t and the only purpose
> of the variables i, n, c and r is to be compared or added to the start
> pointer (also I think it's just ugly to cast size_t down to an int).
>
> On system where int is 32 bit but pointers are 64 bit the compiler might
> need to extend to adjust the size of the operands for the address
> calculation. Right?
>
> Since size_t is unsigned I also had to modify the two loops since I
> can't check for any of the variables becoming negative. Tested with all
> kinds of array sizes.
This is good, but I suspect you'll have Andrew pulling his hair out as
I'll then have to go adjust all the callers and this is already a huge
mess because of the ACL bits from Andreas. As the current code
correctly (but slightly suboptimally) sorts any array size less than a
2G, I think it's safe to hold off on this for a bit. I'll queue this
up for after the sort and ACL stuff gets merged.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2005-03-01 20:13 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-31 7:34 [PATCH 0/8] lib/sort: Add generic sort to lib/ Matt Mackall
2005-01-31 7:34 ` [PATCH 1/8] lib/sort: Heapsort implementation of sort() Matt Mackall
2005-01-31 7:34 ` [PATCH 2/8] lib/sort: Replace qsort in XFS Matt Mackall
2005-01-31 7:35 ` [PATCH 3/8] lib/sort: Replace qsort in NFS ACL code Matt Mackall
2005-01-31 7:35 ` [PATCH 4/8] lib/sort: Kill qsort() Matt Mackall
2005-01-31 7:35 ` [PATCH 5/8] lib/sort: Replace open-coded O(pids**2) bubblesort in cpusets Matt Mackall
2005-01-31 7:35 ` [PATCH 6/8] lib/sort: Replace insertion sort in exception tables Matt Mackall
2005-01-31 7:35 ` [PATCH 7/8] lib/sort: Replace insertion sort in IA64 " Matt Mackall
2005-01-31 7:35 ` [PATCH 8/8] lib/sort: Use generic sort on x86_64 Matt Mackall
2005-01-31 12:02 ` [PATCH 5/8] lib/sort: Replace open-coded O(pids**2) bubblesort in cpusets Paul Jackson
2005-02-01 22:29 ` [PATCH 2/8] lib/sort: Replace qsort in XFS Chris Wedgwood
2005-02-01 22:22 ` Randy.Dunlap
2005-02-02 4:31 ` Zan Lynx
2005-02-02 10:48 ` Herbert Xu
2005-02-01 22:48 ` Matt Mackall
2005-01-31 17:16 ` [PATCH 1/8] lib/sort: Heapsort implementation of sort() Andreas Gruenbacher
2005-01-31 17:30 ` Paulo Marques
2005-02-01 17:54 ` Andreas Gruenbacher
2005-02-01 18:11 ` linux-os
2005-02-01 19:04 ` linux-os
2005-02-01 19:47 ` Andreas Gruenbacher
2005-01-31 19:30 ` Matt Mackall
2005-02-01 17:50 ` Andreas Gruenbacher
2005-02-02 1:00 ` Horst von Brand
2005-02-02 10:50 ` Herbert Xu
2005-02-02 11:14 ` Andreas Gruenbacher
2005-02-03 23:19 ` Junio C Hamano
2005-02-01 2:10 ` Horst von Brand
2005-02-27 13:17 ` Andreas Gruenbacher
2005-02-27 21:25 ` Matt Mackall
2005-02-27 21:53 ` Andreas Gruenbacher
2005-02-27 22:10 ` Andreas Gruenbacher
2005-03-01 13:23 ` Andreas Gruenbacher
2005-03-01 19:06 ` Christophe Saout
2005-03-01 20:12 ` Matt Mackall [this message]
2005-03-01 21:47 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2005-01-31 11:52 Alexey Dobriyan
2005-01-31 16:53 ` Matt Mackall
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=20050301201241.GM3120@waste.org \
--to=mpm@selenic.com \
--cc=agruen@suse.de \
--cc=akpm@osdl.org \
--cc=christophe@saout.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.