🚀 go-pugleaf

Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
> > In all of your examples
> > the behaviour can vary depending on the actual implementation of qsort().
> > In the absense of any other limitation in the standard (such as a statement
> > of implementation-defined behaviour), this means the behaviour is undefined.
 
Clive Feather (cdwf@cityscape.co.uk) writes:
> No, this is circular logic.  A library function must be inferred to do
> only what its specification says, and nothing else; you can't use
> undescribed behaviour to deduce that a specific call to that function
> is undefined.

Sorry, Clive, but that doesn't wash; Lawrence is right.  Before you can
say that a library function does "only what its specification says", that
specification has to be meaningful.  Well, this particular library function
is specified as sorting "according to [the] comparison function".  Since
the sequence and timing of the calls that qsort() makes to the comparison
function is not specified, it follows that the specification of qsort()
is meaningful only if it is independent of that sequence and timing.
If it ISN'T indedependent, the behavior of qsort() is undefined.

(Similarly, if the comparison function returns inconsistent values --
if it is nontransitive or non-antisymmetric -- again it is not meaningful
to sort "according to" it.  So the behavior is undefined there also.)
-- 
Mark Brader              |  ...the scariest words of the afternoon:
msb@sq.com               |   "Hey, don't worry, I've read all about
SoftQuad Inc., Toronto   |    doing this sort of thing!"    -- Vernor Vinge

My text in this article is in the public domain.