[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260419010956.GH1827@brightrain.aerifal.cx>
Date: Sat, 18 Apr 2026 21:09:56 -0400
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com, David Sparks <sparks05@...ton.me>
Subject: Re: Some additional qsort patches
On Sun, Apr 19, 2026 at 03:03:10AM +0200, Thorsten Glaser wrote:
> On Tue, 14 Apr 2026, David Sparks wrote:
>
> > src/stdlib/qsort.c: Use plain "char" for opaque data
> >
> > "unsigned char" is more typing and inconsistent with the libc
> > interface conventions. It's all internal, anyway.
>
> I’d be *very* wary of this.
>
> In case of doubt, unsigned types are the correct choice, in general.
>
> In specific, unsigned chars compare different to maybe-signed ones.
>
> (I’ve not looked at the code in question, but I do recall debugging
> failures from using signed chars.)
In this case it's just used as an abstract char type you can do
pointer arithmetic within the array on, so it shouldn't break
anything. But I'm not going to accept gratuitous style change patches
like this. I'm not going to make people who care about their security
do before-and-after compile tests to make sure the codegen is
identical, or spend their time reading and reasoning about whether the
change made any difference. Whatever way the author of the code wrote
it is fine as long as it's not incorrect.
Rich
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.
