🚀 go-pugleaf

[ This is from a committee member who is more knowledgeable than I.
The usual disclaimers about not necessarily representing the official
position of IEEE, P1003, etc. apply.  -mod ]

From: athena!steved%tektronix.csnet@CSNET-RELAY.ARPA
Date: Tuesday, 19 Nov 85 10:27:06 PST

-----
John, 

In response to Dan Franklin's letter about changes in the standard concerning
the misleading (and sometimes contradictory) wording in the limits section.
In preparing draft 6, this section was cleaned up by the technical reviewers.

The body of the paragraph now says that the magnitude of the defined value 
must be greater than or equal to the magnitude of the value specified and
they must be of the same sign.  Also the column is simply labeled "Value".

This should clear up the ambiguity of the section.

On the question of these values being obtainable dynamically,  The intention
of this section is to present minimum magnitudes that the implementer can
be certain of having for a given implementation.  I.E. if the designer
makes sure that his application fits (so to speak) within these limits
it will work on any system.  I feel that the question of querying the values
at run time is really a different topic.  There really needs to be the two
classes of limits available. The limits file is not intended to represent
necessarily the current limit.  For example, PROC_MAX tells an application
programmer that he knows that there can be n processes existing simultaneously.
However, the o.s. implementer may have some dynamic allocation scheme where
the actual limit varies with say system load.  The goal of the standard is to
allow that kind of implementation.

The working committee will certainly accept and consider proposals for a 
routine that would provide the more esoteric program the ability to dynamically
determine what "current" limits are.  Clearly the case of the shell, wanting
to close all unused file descriptors is a good case for the routine.

Volume-Number: Volume 3, Number 30