Re: glibc qsort() vulnerability
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Heikki Linnakangas <hlinnaka@iki.fi>, Mats Kindahl <mats@timescale.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2024-02-08T02:38:10Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use new overflow-safe integer comparison functions.
- 3b42bdb47169 17.0 landed
-
Introduce overflow-safe integer comparison functions.
- 6b80394781c8 17.0 landed
-
Replace calls to pg_qsort() with the qsort() macro.
- 5497daf3aa2a 17.0 landed
-
Switch over to using our own qsort() all the time, as has been proposed
- 6edd2b4a91bd 8.2.0 cited
On Thu, Feb 8, 2024 at 3:06 PM Andres Freund <andres@anarazel.de> wrote: > On 2024-02-07 19:52:11 -0600, Nathan Bossart wrote: > > On Wed, Feb 07, 2024 at 04:42:07PM -0800, Andres Freund wrote: > > > On 2024-02-07 16:21:24 -0600, Nathan Bossart wrote: > > >> The assembly for that looks encouraging, but I still need to actually test > > >> it... > > > > > > Possible. For 16bit upcasting to 32bit is clearly the best way. For 32 bit > > > that doesn't work, given the 32bit return, so we need something more. > > > > For the same compASC() test, I see an ~8.4% improvement with your int64 > > code > > Just to be clear, that code unfortuntely isn't correct, the return value is a > 32 bit integer, so the 64bit difference doesn't help. In contrast to the 16bit > case. Perhaps you could wrap it in a branch-free sign() function so you get a narrow answer? https://stackoverflow.com/questions/14579920/fast-sign-of-integer-in-c