home *** CD-ROM | disk | FTP | other *** search
- 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
-
-