>> If you can find me a description of what NetBSD assumes beyond what >> C promises, [...] > I don't think we have such a list.
I didn't think so either, but wasn't nearly sure enough to assume there wasn't one. > [...]. 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. Then there are a lot of things that need fixing; the one I'm most aware of is the assumption that all-bits-0 is a nil pointer. (This most often shows up in the use of calloc, bzero, etc on space that includes a pointer and then assuming the pointer is nil; see, for example, the example code in 5.2's getaddrinfo(3) manpage.) > (Also, as far as 8-bit types, while POSIX promises that char is 8 > bits wide, [...] Exactly 8 bits, or at least 8 bits? C promises it's at least 8 bits; that isn't one of the things I had heard that POSIX said anything about. > [...] 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.) 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....) > 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. Or anything else less than 32, I suspect. I would even hazard a guess that there's code in the tree that assumes int is exactly 32 bits, though code assuming long is also 32 has most probably been eradicated by now. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B