[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dW8_QFeGEnfY-VghgQxDAyYo1aRd5k-TNp7SvcuLLp7g3Ain6k4aUkPgeLCJn6QxiFIt8xZEfiBAvnUUmOOABf0MWOSZdrK8aE4EEgrh8Nc=@proton.me>
Date: Sat, 25 Apr 2026 13:36:15 +0000
From: David Sparks <sparks05@...ton.me>
To: Bartosz Brachaczek <b.brachaczek@...il.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>, "dalias@...ifal.cx" <dalias@...ifal.cx>, "mailto.luca.kellermann@...il.com" <mailto.luca.kellermann@...il.com>
Subject: Re: Some additional qsort patches
On Saturday, April 25th, 2026 at 11:24, Bartosz Brachaczek <b.brachaczek@...il.com> wrote:
> The largest possible array on 32-bit is 2GB (PTRDIFF_MAX). I reported what I wrongly thought was a bug in the loop filling the lp array for ~3GB inputs privately to Rich and he pointed me to https://www.openwall.com/lists/musl/2016/01/09/2
Ah! Thank you! That dumps the entire issue into the
"can't happen; just ignore it" pile, which is what I
was hoping for in the first place.
On Saturday, April 25th, 2026 at 11:24, dalias@...ifal.cx <dalias@...ifal.cx> wrote:
> If you need 66 entries, the length would just need to be increased to
> 128 entries (next largest power of 2).
Yes, I know that's definitely a possible solution. I just thought
an additional 4*64 = 256 bytes on the stack *which will never be used*
was ugly and wasteful, as cycle() establishes 256 bytes as a
"reasonable stack buffer".
Using the same formula on 64 bits would be >1024 wasted bytes. :-(
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.
