Re: qsort_r

[Mouse <mouse%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));

Yes.

> That one is perfectly fine, in any C, the values of the pointer
> fields of hints are irrelevant,

According to the manpage, their values are relevant:

     All other elements of the addrinfo structure passed via hints 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 would disagree that "all zero bits" is a reasonable choice for what
it means for a pointer to "be zero", unless all zero bits happens to be
the implementation's choice for a nil pointer.  It's a C interface; I
have trouble interpreting "be zero" as anything but "hold a value which
compares equal to zero", which for pointers means a nil pointer.

In any case, it's hardly the only example of that assumption; it's just
the first one that came to mind.

> Of academic use only - [...]

> I'm all for additions/corrections/... that aid writing more correct,
> and more portable code - that's always a good thing.

That's exactly what such a checkout compiler would be for.  Indeed, to
be really useful it would need to have some kind of controls for
exactly which assumptions it breaks, so that, for example, you could
tell it to make nil pointers all-0-bits but break the assumption that
int has no padding bits in it.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B