std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/16/85)
Date: Fri, 15 Nov 85 11:53:55 EST From: Dan Franklin <dan@BBN-PROPHET.ARPA> Some of the values in the column "Minimum value" are actually maximums rather than minimums, and the draft should indicate this. That is, for the minimums CHAR_MIN, INT_MIN, LONG_MIN, and SHRT_MIN, the column gives the maximum permissible value (as it should), not the minimum permissible. Before I realized this, I thought it was an error that the "minimum value" for CHAR_MIN was 0 rather than -128. One way to make this clearer would be to change the column label "Minimum value" to "Minimum (Maximum) value" and put the values which are actually "largest permissible minimums" rather than "smallest permissible maximums" in parentheses. Dan [ This comes up at every meeting. Your method looks as good as any. -mod ] Volume-Number: Volume 3, Number 23
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/20/85)
Date: Mon, 18 Nov 85 13:55:26 cst From: ihnp4!uiucdcs!ccvaxa!preece@SEISMO.CSS.GOV (Scott Preece) > [ This comes up at every meeting. Your method looks as good as any. > -mod ] ---------- Will there be a "Guide for voters" describing some of the things that "come up at every meeting"? [ There will be numerous and voluminous appendices, many of which will serve that purpose (though they don't use that phrase :-). This newsgroup also serves that purpose to some extent. -mod ] Volume-Number: Volume 3, Number 26
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/20/85)
[ 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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/23/85)
Date: Fri, 22 Nov 85 09:34:32 cst From: ihnp4!uiucdcs!ccvaxa!preece@SEISMO.CSS.GOV (Scott Preece) > From: athena!steved%tektronix.csnet@CSNET-RELAY.ARPA > 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. ---------- There are a lot of error definitions in the draft that specifically say that specific, named system limits have been exceeded. For instance, the fork error code mention PROC_MAX and CHILD_MAX. If the limit is, in fact, dynamic or otherwise differs from the named constant, you are causing confusion... [ Yes, it's hard to find non-confusing language to describe this. -mod ] -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece Volume-Number: Volume 3, Number 39
std-unix@ut-sally.UUCP (John Quarterman, Moderator) (11/26/85)
Date: Mon, 25 Nov 85 11:35:46 pst From: saber!msc@ihnp4.uucp (Mark Callow) > [discussion by steved@athena and Scott Preece on limits.h, dynamic > limits and error message definitions in the draft (deleted for brevity)] > > [ Yes, it's hard to find non-confusing language to describe this. -mod ] ------------ "Non-confusing language" is only hard to find when the idea that you are describing is confused. [ Draft 6 is now available (see announcement in next article). Suggest you look at the current wording in it, and propose new wording which describes the appropriate ideas in non-confusing language. -mod ] Volume-Number: Volume 3, Number 42