Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: forsyth%minster.york.ac.uk@nsfnet-relay.ac.uk
Newsgroups: comp.sys.sun
Subject: qsort bug?
Keywords: SunOS
Message-ID: <345@brazos.Rice.edu>
Date: 21 Jul 89 15:14:21 GMT
Sender: news@rice.edu
Organization: Sun-Spots
Lines: 15
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 81, message 15 of 15

By accident, someone here wrote a qsort comparison function that was
inconsistent (it compared the pointers not the values, and different calls
to compare the same [to qsort] objects gave different results).
Naturally, the array of objects wasn't sorted correctly.  More disturbing,
it seems that the BSD(?) based qsort distributed with SunOS has the
unfortunate property that in such cases it can smash memory, probably
because it relies on the comparison function to produce a sentinel value,
and then doesn't keep checking for the end/start of the array thereafter.
(Of course, it presumably finds the sentinel in order to be able to do
that!) Is this a known bug or `feature'?

The v7 qsort.c does not do this; nor does the system V one (the v7 one
modified to use memcpy when appropriate).  Also, the comment in UCB qsort
claims that it runs faster, but that's not my experience on an admittedly
limited sample.  Has anyone tested this claim against v7 and sys5 qsort.c?