Re: qsort_r

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Dec 09, 2013 at 12:59:49AM -0500, Mouse wrote:
 > > [...].  In this environment I don't think it's a good idea to make
 > > any assumptions at all about things the C standard doesn't guarantee.
 > 
 > Then there are a lot of things that need fixing; the one I'm most aware
 > of is the assumption that all-bits-0 is a nil pointer.  (This most
 > often shows up in the use of calloc, bzero, etc on space that includes
 > a pointer and then assuming the pointer is nil; see, for example, the
 > example code in 5.2's getaddrinfo(3) manpage.)

Yes. I think the official stance on that is to worry about it when a
real platform appears where it matters. Myself, I don't write such
code (either for pointers or floats) -- in most cases it is clearer to
initialize explicitly and it's not hard for the compiler to turn a
bunch of explicit initializations into a bzero call if it thinks
that's better. The one family of cases where this isn't so clear is
kernel things where in some cases you get zeroed pages that you know
are zeroed and it's stupid and slow to write more zeros over them
unnecessarily.

 > > (Also, as far as 8-bit types, while POSIX promises that char is 8
 > > bits wide, [...]
 > 
 > Exactly 8 bits, or at least 8 bits?  C promises it's at least 8 bits;
 > that isn't one of the things I had heard that POSIX said anything
 > about.

POSIX says that CHAR_BIT is 8.

 > > [...] there's still from time to time loose talk about doing a port
 > > to a 36-bit machine, where char would presumably be 9 bits.  I think
 > > doing this and making it work this would be good for the general
 > > quality of the code base and I'd rather not introduce unnecessary
 > > complications.)
 > 
 > I agree.  (I've often thought it would be nice to have a checkout
 > compiler that went out of its way to break as many as possible of the
 > usual assumptions that are "true everywhere" but that C does not
 > actually promise....)

Many people think that, but nobody's really done it, as it's a bit of
a large project. Go for it :-)

 > > The one exception to all this that I can think of is that we don't
 > > care about platforms where int is 16 bits wide.  Or 18, either.
 > 
 > Or anything else less than 32, I suspect.  I would even hazard a guess
 > that there's code in the tree that assumes int is exactly 32 bits,

Yeah probably. It's a big tree and there aren't really adequate
checking tools for this.

 > though code assuming long is also 32 has most probably been eradicated
 > by now.

Most of that's even gone from pkgsrc at this point. I've been hunting
it down.

-- 
David A. Holland
dholland%netbsd.org@localhost