🚀 go-pugleaf

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