std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/16/85)
Date: Fri, 15 Nov 85 11:49:49 EST From: Dan Franklin <dan@BBN-PROPHET.ARPA> While we're moving kernel-dependent values out of limits.h into a system call where they belong, it seems only appropriate to list the limits which I believe are appropriate for limits.h, and should stay there. {CHAR_BIT} Maximum number of bits in a datum of type char {CHAR_MAX} Maximum magnitude for a datum of type char {CHAR_MIN} Minimum magnitude for a datum of type char {INT_MAX} (Same for ints) {INT_MIN} {LONG_MAX} (For longs) {LONG_MIN} {SHRT_MAX} (For shorts) {SHRT_MIN} {USI_MAX} (For unsigned ints) {WORD_BIT} Number of bits in a word or datum of type int These limits reflect the architecture of the CPU as viewed through the compiler; they would change only if the CPU architecture or the compiler changed. They can safely be kept in limits.h because if the architecture changed, recompilation would be necessary for other reasons besides getting the value of the limit to be up-to-date; and if the compiler changed, recompilation wouldn't be necessary because the operation of binaries is not affected by changes to the compiler (except perhaps binaries that actually deal with compiler output, like symbol tables and .o files and so on; again, such binaries would need a lot more than just an up-to-date value or two). It's also inappropriate (as well as unnecessary) for the kernel to return these values, since they are not properties of the kernel like {PIPE_MAX}. By the way, why aren't there USL_MAX, USC_MAX, and USS_MAX? (For unsigned longs, chars, and shorts respectively.) Dan Volume-Number: Volume 3, Number 22