Re: qsort_r

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 9 Dec 2013 00:59:49 -0500 (EST)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201312090559.AAA21243%Chip.Rodents-Montreal.ORG@localhost>

  | see, for example, the
  | example code in 5.2's getaddrinfo(3) manpage.)

I assume you mean ....
        memset(&hints, 0, sizeof(hints));

That one is perfectly fine, in any C, the values of the pointer
fields of hints are irrelevant, they're never used (we may wonder
at the interface design that used a struct addrinfo for this purpose,
but that's beyond fixing now).   Only the int fields of the hints struct
have any defined use - the others "must be zero or the null pointer."
(It doesn't say that the pointer fields must be the null pointer, and
other fields must be zero, though that would be a sane implementation,
just that the other fields must each be 0, or be the null pointer,
the memset() makes them all be 0 - which conforms with the requirements.)


  | 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....)

Of academic use only - in the real world economics (that existing code,
however badly written, that works today, must also work on future systems,
or no-one will buy them) puts all kinds of limitations on what hardware
designers are able to do, other than for very special purpose uses,
which NetBSD is never going to care about.

What the C standards people, and then the gcc implementors, are doing is
apalling - changing (or even just tightening) the spec to allow for
processor designs that once existed, but will never be seen again, or
that allow optimisations to make code run raster, when what needs optimisation
most is programmer effort, if we have programmers fighting against arcane
language rules that compiler implementors have used to make some code
segment run a few seconds faster, rather than doing the "obvious" intended
operation, then everyone suffers, and "but the rules say we can do that,
and you shouldn't have assumed that we wouldn't" are no consolation at all.

I'm all for additions/corrections/... that aid writing more correct, and
more portable code - that's always a good thing.  But changes that force
the writing of any of that, rather than simply promote it, are evil.

C used to be a great language, precisely because it didn't get in the
way, and make programmers much more productive.   These days, much of
that has gone, and it is becoming just another obstruction to getting
work actually done.

kre