tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: qsort_r
On Sun, Dec 08, 2013 at 11:51:15PM -0500, Mouse wrote:
> If you can find me a description of what NetBSD assumes beyond what C
> promises, I can have a stab at answering that question. (I know a few
> of the things, such as "there is an exactly-8-bit type", but I feel
> fairly sure I don't know them all; I'm even now still discovering such
> things occasionally.)
I don't think we have such a list. In practice though it's defined by
what properties all "normal" architectures share, filtered by which of
these properties gcc reliably allows to show through to the source
level. This is a moving target; for example, not all that long ago you
could rely on signed shifts to behave properly, but nowadays you
can't.
Historically the C standard was understood to provide certain wiggle
room for the architecture and other wiggle room for the compiler, such
that people writing MD code could reasonably assume that properties of
their architecture would be reflected through by the compiler. The gcc
guys have repeatedly demonstrated that they have no use for this model,
no interest in preserving such properties, and are willing to break
them arbitrarily. In this environment I don't think it's a good idea
to make any assumptions at all about things the C standard doesn't
guarantee.
(Also, as far as 8-bit types, while POSIX promises that char is 8 bits
wide, there's still from time to time loose talk about doing a port to
a 36-bit machine, where char would presumably be 9 bits. I think doing
this and making it work this would be good for the general quality of
the code base and I'd rather not introduce unnecessary complications.)
The one exception to all this that I can think of is that we don't
care about platforms where int is 16 bits wide. Or 18, either.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index