Re: qsort_r

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

On Mon, Dec 09, 2013 at 01:49:29AM -0500, Mouse wrote:
 > >> 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.
 > > Yes.  I think the official stance on that is to worry about it when a
 > > real platform appears where it matters.
 > 
 > So, rather than start fixing it now, at leisure, a big scramble when it
 > actually becomes important is preferable?  Well, I suppose it's their
 > collective neck - or, rather, their project's.

Well... what is a plausible scenario where this becomes important? In
what situation is someone going to try to change this convention, or
more accurately, in what situation is someone going to try to change
this convention in a way that makes it time-critical to fix problems
that arise, such that necks become involved?

The only cases I can think of are deliberately working this issue out
with suitable tools, and porting to some vintage machine where you
can't for some reason use 0 as the null pointer representation.
Neither is exactly an urgent situation.

No new machine will ever have this property because there's too much
existing code that would break and there's no plausible reason to
bother.

Similarly, for all-bits-0 floats, no new machine is going to use
anything but IEEE floats.

 > > 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 possible in userland, though less commonly.

Vanishingly rarely; I suppose calloc can avoid rezeroing when it gets
fresh pages from the kernel, but does any calloc actually *do* that
rather than just calling malloc and bzero?

 > >> (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 :-)
 > 
 > Heh.  Yeah, perhaps some one of these years I'll find the spare time to
 > start seriously hacking compilers.

If you keep worrying about how porky gcc is, sooner or later you'll
get irritated enough to write your own...

 > >> 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.
 > 
 > Checkout compiler!  NetBSD/pdp10!  :-)

One of the reasons I proposed/started on "mint" was to enable checks
for stuff like this. But I haven't really put any time into it yet...

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