Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/mod.std.unix.v3

Internet Message Format | 1987-06-30 | 105KB

From jsq  Sun Nov  3 13:13:26 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix Volume 3
Message-Id: <[e-mail]>
Date: 3 Nov 85 19:13:20 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 35
Approved: [e-mail]
Draft-9: mod.std.unix

As I gave a paper copy of volumes one and two of mod.std.unix to the
P1003 chair at the Steering Group meeting in Dallas, it is convenient
to start Volume 3, of which this is Number 1.  Friday was not the first
time the committee had seen articles from the newsgroup, by the way,
since several members follow it closely and I tend to directly forward
specific articles of interest to the chair.  Your input is seen and
taken into account.


The USENET newsgroup mod.std.unix is for discussions of UNIX standards,
particularly the IEEE P1003 draft standard.  It is also distributed
in an ARPA Internet mailing list.  I'm the moderator, which mostly
means I post what you send me.

Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix

Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

Archives may be found on sally.UTEXAS.EDU.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
as ~ftp/pub/mod.std.unix, while the previous volumes may be retrieved
as ~ftp/pub/mod.std.unix.v1 and ~ftp/pub/mod.std.unix.v2.

Finally, remember that any remarks by any committee member (especially
including me) in this newsgroup do not represent any position (including
any draft, proposed or actual, of the standard) of the committee as a
whole, unless explicitly stated otherwise in such remarks.

Volume-Number: Volume 3, Number 1

From jsq  Sun Nov  3 13:34:21 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: public domain AT&T getopt source
Message-Id: <[e-mail]>
Date: 3 Nov 85 19:34:15 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 91
Approved: [e-mail]
Draft-9: 1003.2.getopt

Here's something you've all been waiting for:  the AT&T public domain
source for getopt(3).  It is the code which was given out at the 1985
UNIFORUM conference in Dallas.  I obtained it by electronic mail
directly from AT&T.  The people there assure me that it is indeed
in the public domain.

There is no manual page.  That is because the one they gave out at
UNIFORUM was slightly different from the current System V Release 2
manual page.  The difference apparently involved a note about the
famous rules 5 and 6, recommending using white space between an option
and its first argument, and not grouping options that have arguments.
Getopt itself is currently lenient about both of these things White
space is allowed, but not mandatory, and the last option in a group can
have an argument.  That particular version of the man page evidently
has no official existence, and my source at AT&T did not send a copy.
The current SVR2 man page reflects the actual behavor of this getopt.
However, I am not about to post a copy of anything licensed by AT&T.

I will submit this source to Berkeley as a bug fix.

I, personally, make no claims or guarantees of any kind about the
following source.  I did compile it to get some confidence that
it arrived whole, but beyond that you're on your own.


/*LINTLIBRARY*/
#define NULL    0
#define EOF    (-1)
#define ERR(s, c)    if(opterr){\
    extern int strlen(), write();\
    char errbuf[2];\
    errbuf[0] = c; errbuf[1] = '\n';\
    (void) write(2, argv[0], (unsigned)strlen(argv[0]));\
    (void) write(2, s, (unsigned)strlen(s));\
    (void) write(2, errbuf, 2);}

extern int strcmp();
extern char *strchr();

int    opterr = 1;
int    optind = 1;
int    optopt;
char    *optarg;

int
getopt(argc, argv, opts)
int    argc;
char    **argv, *opts;
{
    static int sp = 1;
    register int c;
    register char *cp;

    if(sp == 1)
        if(optind >= argc ||
           argv[optind][0] != '-' || argv[optind][1] == '\0')
            return(EOF);
        else if(strcmp(argv[optind], "--") == NULL) {
            optind++;
            return(EOF);
        }
    optopt = c = argv[optind][sp];
    if(c == ':' || (cp=strchr(opts, c)) == NULL) {
        ERR(": illegal option -- ", c);
        if(argv[optind][++sp] == '\0') {
            optind++;
            sp = 1;
        }
        return('?');
    }
    if(*++cp == ':') {
        if(argv[optind][sp+1] != '\0')
            optarg = &argv[optind++][sp+1];
        else if(++optind >= argc) {
            ERR(": option requires an argument -- ", c);
            sp = 1;
            return('?');
        } else
            optarg = argv[optind++];
        sp = 1;
    } else {
        if(argv[optind][++sp] == '\0') {
            sp = 1;
            optind++;
        }
        optarg = NULL;
    }
    return(c);
}

Volume-Number: Volume 3, Number 2

From jsq  Sun Nov  3 16:43:52 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Comments on UNIX command option syntax
Message-Id: <[e-mail]>
Date: 3 Nov 85 22:43:32 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 231
Approved: [e-mail]
Draft-9: 1003.2.getopt

[ I've picked this up from net.unix.  It explains what the rules 5 and 6 are,
regarding getopt(3).  -mod ]

>From: [e-mail] (Gary Perlman)
Date: 30 Oct 85 18:03:01 GMT

I tried to post this to mod.std.unix, but it got bounced by the mailer.  Sigh.
------------------

                 Proposed Syntax Standard
                 For UNIX* System Commands

RULE  1:  Command names must be between 2 and 9 characters.

RULE  2:  Command names must include lower case letters and
          digits only.

RULE  3:  Option names must be a single character in length.

RULE  4:  All options must be delimited by ``-''.

RULE  5:  Options with no arguments may be grouped behind
          one delimiter.

RULE  6:  The first option-argument following an option
          must be preceded by white space.

RULE  7:  Option arguments cannot be optional.

RULE  8:  Groups of option-arguments following an option must be
          separated by commas or separated by white space and quoted.

RULE  9:  All options precede operands on the command line.

RULE 10:  ``--'' may be used to delimit the end of the options.

RULE 11:  The order of options relative to one another
          should not matter.

RULE 12:  The order of operands may matter and position-related
          interpretations should be determined on a
          command-specific basis.

RULE 13:  ``-'' preceded and followed by white space should be used
          only to mean the standard input.

                                                  November 1983
*UNIX is a trademark of AT&T Bell Laboratories

--------------------------------------------------------------------

The above  is a  direct quote  of the  quick reference  card
handed out in  conjunction with  a talk at  the 1984  Winter
Usenix conference by K. Hemenway & H. Armitage.  This set of
rules is sometimes called the H&A standard.  Any proposal of
a standard is  going to  cause controversy, and  this is  no
exception.  Although I at first was opposed to the standard,
I came to appreciate the thought that went into it.  In this
commentary, I hope to convey that to you.

General comments: The H&A standard tries to maintain as much
compatibility with  existing  programs while  improving  the
consistency of  UNIX  command line  syntax.   This  is  much
harder than designing  a command line  syntax from  scratch.
It is important to understand the rationale behind the whole
set of  conventions  before  making  judgements  about  them
individually.

H&A recorded the  syntax for  all the commands  in UNIX  (at
least System V UNIX).  They tried to come up with a standard
that was  as  close to  most  of the  existing  commands  as
possible.  Their analysis, summarized in their USENIX paper,
but much better covered in an unavailable internal Bell Labs
tech report, is an  excellent example of backing  statements
with facts.  The most common example of an objection to  the
standard is of the  form, "I don't like  RULE X. What  about
the zz command?"  to which  H&A could  say, "That  exception
happens in  only N  (few) commands."  Here are  my  comments
about the rules.  They contain my reaction to the rules  and
some of H&A's reasons for the rules.

I want to start by saying that this standard is much  better
than no standard.   If  I know  that a  command follows  the
standard, then there are no surprises about how options  are
requested and that makes life easier  for me.  I don't  have
to  worry  about  inconsistency,  and  that  overwhelms  the
quirks of the standard.

RULE 1:
          I see no reason for not allowing single  character
          command names like e, f,  w, and S, but there  are
          not many of  these.   There is  not much  mnemonic
          value to  single  character commands,  nor  for  2
          character commands, but there are a lot of those.

RULE 2:
          The restriction to lower case letters only is  for
          case insensitive systems.   One notable  exception
          is a.out, but that is  not really a command  name.
          Not allowing  special characters  like  underscore
          simplifies the rules.

RULE 3:
          Single  character  option   names  are  not   very
          mnemonic, but  they are  necessary to  be able  to
          bundle options.  They are also used in most of the
          commands.     Their   lack   of   mnemonicity   is
          compensated somewhat when on-line help is  readily
          available, which unfortunately is not common.

RULE 4:
          The convention of preceding options with - started
          to distinguish  options  from file  names.    Some
          commands that do not  take operands like files  or
          expressions  do  not  require  the  -  sign.    My
          experience is  that  this  is  an  extra  rule  to
          explain to new  users that is  not worth saving  a
          keystroke here and there.

RULE 5:
          Bundling of options  was a rule  demanded by  UNIX
          fans inside Bell Labs.  Once you accept this rule,
          you can't  have  multiple character  options,  and
          this is unfortunate.  Still,  I would not like  to
          have to type: ls -l -t -r.

RULE 6:
          Many programs  require  that  an  option  argument
          immediately follow the option (e.g., cc -lm, nroff
          -man) while  some require  a  space (e.g.,  cc  -o
          pgm).  This is  one inconsistency that causes  the
          most problems  for me, especially when  there  are
          inconsistencies inside a command  (cf.  cc,  which
          passes the  tightly  grouped  option-arguments  to
          other  programs).     Rather   than  deciding   on
          no-space, a space is required in the H&A standard.
          This is to make sure that filename expansion works
          properly.   For example,  if  the argument  to  an
          option is a  file like  "extralongname", then  the
          option -fextra*  would not  work, while  having  a
          space in there would.   You could make the  syntax
          "space-optional" but that  would require that  the
          documentation cover more  than one  case, which  I
          argue would make the syntax harder to learn.

RULE 7:
          Because option  arguments must  be separated  from
          options,  there  is  no  way  to  make  an  option
          argument optional, except for the special case  of
          at the end of a command line with no operands (but
          I think  this  rare  exception would  be  hard  to
          explain).   There  are  few  commands  that  allow
          optional  option-arguments  (e.g.,  pr  -h),   and
          supplying a  null argument  (ie.   "")  works  are
          well.

RULE 8:
          This rule does not allow for syntax like:
              pgm -i file1 file2 file3 -o file4 file5
          but this  is  not  very common.    Placing  quotes
          around the files is not too bad.

RULE 9:
          When options must  precede operands (e.g.,  files)
          several practices  are  not  supported.    One  is
          choosing a set  of options for  one file and  then
          some options for another.  Instead of this, two or
          more command lines are needed,  but this is not  a
          serious penalty  for  most  commands,  and  not  a
          common need.  The  second unsupported practice  is
          that of thinking of  options after typing most  of
          the  command   line;  if   options  must   precede
          operands, then they must be inserted.  While  this
          can be awkward  for some primitive  shells, it  is
          best handled with  command line  editing, such  as
          that in ksh.

RULE 10:
          You really need -- to  delimit the end of  options
          so that files or expressions that begin with - can
          be processed.  The string  -- was used because  of
          getopt's use.   This is not  a strong  motivation,
          because at the time of the standard, only about 40
          commands used getopt.  Still,  it seems as good  a
          delimiter as any.


RULE 11:
          I do not know why the order of options should  not
          matter.  It does matter  in commands like cc  (ie.
          ld) that requires a special ordering to libraries.

RULE 12:
          This rule says that the programmer can choose  any
          meaning to what follows the options.  Makes  sense
          to me.

RULE 13:
          There is some tradition and a definite need to  be
          able to insert the standard  input into a list  of
          files.  The - has been used in a few commands, and
          there were no likely contenders.

My impression is that  the H&A standard is  one we can  live
with.   It is  not the  sort of  syntax that  someone  might
design from scratch, but there  is a need for  compatibility
with old  syntax, not  just for  user comfort,  but also  to
avoid breaking  thousands  of shell  scripts  and  system(3)
calls to UNIX command lines.  Yes, there is some more typing
required, but I think it  is not a high  price to pay for  a
set of conventions you can fit on a small card.  To get  all
the  time-savers  we  like,   the  syntax  gets  much   more
complicated, which  I  think  is  one  reason  for  the  bad
reputation UNIX has earned.

What about existing commands?  Last I heard, the plan was to
first work on the  easy cases, the  commands that were  very
close to the standard.   Some commands would not be  changed
but be replaced  by new  programs that would  phase out  the
old.   Some  examples of commands  with extremely  difficult
syntax are "pr" and "sort".  The "test" command is  finessed
by saying  that  it does  not  use options,  but  a  special
expression language.  The "find" command could be dealt with
similarly.    The  "dd"  command,  with  name-value   format
options, originally  designed as  a parody  of the  IBM  DD,
would not change.
--
Gary Perlman  Wang Institute  Tyngsboro, MA 01879  [phone]
UUCP: decvax!wanginst!perlman             CSNET: perlman@wanginst

Volume-Number: Volume 3, Number 3

From jsq  Wed Nov  6 18:14:28 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: lost mail
Message-Id: <[e-mail]>
Date: 7 Nov 85 00:14:13 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 5
Approved: [e-mail]
Draft-9: mod.std.unix

Someone mailed me a followup to the previous article.
I'm afraid I managed to lose it during a fire drill this morning,
and I don't remember who it was.  Could you please mail another copy?

Volume-Number: Volume 3, Number 4

From jsq  Fri Nov  8 20:38:33 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Is SIGILL omitted from the list of "hardware" signals for good reason?
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:38:27 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 53
Approved: [e-mail]
Draft-9: 3.3.1

This is the first of a series of articles consisting mostly of mail
items from Robert Elz about P1003 Draft 4.  They have all been given to
the appropriate section reviewers on the P1003 committee and will be
taken into account during the Trial Use balloting process.  They are
interspersed here with comments by Doug Gwyn (marked -Gwyn) which
arrived by mail after Draft 5 was available but before the Dallas
Steering Group meeting.  Comments from Don Kretsch (marked -Kretsch)
were collected at the Dallas meeting.  I have added some more (marked
-jsq) while preparing these articles for posting.  All the latter three
people are members of the P1003 working group.  Don Kretsch is also a
member of X3J11 and is the main liaison between the two committees.

The usual disclaimer applies:  nothing posted in this newsgroup
by a committee member necessarily represents the official
position of IEEE, P1003, or any other organization.

Submissions do not ordinarily sit around for a month before
appearing in the newsgroup.  The original poster explicitly
requested that responses be collected and posted with his originals.

The comments on the original remarks are not necessarily definitive,
and the set of people who made them is pretty arbitrary.
Further responses are solicited.

Date: 06 Oct 85 19:26:29 +1000 (Sun)
Subject: Is SIGILL omitted from the list of "hardware" signals for good reason?
>From: Robert Elz <munnari![e-mail]>

In P1003/D4, section 3.3.2 (Signal Processing), there are several
mentions to a list of distinguished signals, being

    SIGTRAP SIGIOT SIGEMT SIGFPE SIGBUS and SIGSEGV

These are the signals to which non-recoverable hardware errors
should be mapped, the action taken upon return from a signal
handler after one of these signals is undefined, and SIGABRT
is to be mapped to one of these.

I note the absense of SIGILL from this list, and wonder why?

Was this deliberately omitted - in which case I object, as
a SIGILL is quite likely the best choice for SIGABRT, and it
certainly may be undefined what will happen upon return
from a SIGILL signal handler.  Or is this a mere oversight?

[ SIGILL was added for Draft 5.  For some reason, Draft 5
still does not permit SIGABRT to be defined as SIGILL; I
don't understand why not.  I thought it was going to be
allowed; only SIGFPE should be disallowed as SIGABRT. -Gwyn ]

Robert Elz        seismo!munnari!kre    [e-mail]

Volume-Number: Volume 3, Number 5

From jsq  Fri Nov  8 20:38:56 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: The variable "errno".
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:38:51 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 51
Approved: [e-mail]
Draft-9: 2.5

Date: 06 Oct 85 19:19:53 +1000 (Sun)
>From: Robert Elz <munnari![e-mail]>

Section 2.3 of draft 4 [ Section 2.4 of Draft 5 -jsq ]
of working group P1003 of (etc, etc of) IEEE states

    Errno is not changed on successful calls, ...

This is a stronger statement than I would like to see.  Again,
my reason is that this introduces a distinction between the
magic "system call" and the ordinary "library routine".

[ No, it removes a distinction between them.  It is really a
misfeature that some library routines set errno when they
have not failed. -Gwyn ]

Much better would simply be to state (as I believe the ANSI
C working group's draft states - though I can't find my copy
right now) that "errno is defined only after unsuccessful
calls to routines where it is explicitly stated to be set".

That is, it is only meaningful to test errno after a function
call that has returned an error indication, where that function
has been documented to set errno to indicate the cause of the
error.  That includes all system calls, and some library routines.

[ This is essentially what Draft 5 says about testing errno,
although its wording is slightly confusing.  -Gwyn ]

[ Which is exactly the problem:  even if you already know what it was
supposed to mean, you have to read it a few times to see if it really
does.  This problem was mentioned by several people at the Steering
Group meeting in Dallas.  However, that group was not authorized by the
committee to make substantive changes to the actual draft.  But we did
add a note in an Appendix explaining the problem, what the X3J11 draft
currently says, and a proposed better wording.  This will appear in
Draft 6, so that it can be taken into account during the Trial Use
balloting.  I do not unfortunately have the text of that note, as I
don't have Draft 6 yet.

Don Kretsch plans to propose the same wording as that of the D6
appendix to X3J11 as a replacement for their current wording.
-jsq ]

With the caveat on the use of "errno" in section 3.3.2.5 I
wonder if perhaps its days are not numbered.  I would have
to think what might replace it though.

Robert Elz        seismo!munnari!kre    [e-mail]

Volume-Number: Volume 3, Number 6

From jsq  Fri Nov  8 20:39:19 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: CHILD_MAX as a constant - is it meaningful?
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:39:14 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 58
Approved: [e-mail]
Draft-9: 2.9

Date: 06 Oct 85 18:53:05 +1000 (Sun)
>From: Robert Elz <munnari![e-mail]>

Section 2.7 of P1003 draft 4 [ Section 2.8 of Draft 5 -jsq ]
requires that implementations must define values of certain
constants in <limits.h>.

One of the required constants is CHILD_MAX, the maximum number
of offspring per userid.

This definition is a little to vague to be useable (it most likely
intends to specify the maximum number of processes per userid, it may
be debated whether the first process for a userid is an "offspring",
it is also unlear whether this applies to "offspring" from some
particular process - perhaps the maximum number of processes a user
is permitted to run per login session?)

This can easily be fixed, but I have a more serious complaint:

Specifying per-userid limits as constants (that is, requiring
an implementation to specify such a constant, and constraining
it to a minimum value of that constant) does not seem to be
an intelligent thing to do.

Ideally, per-userid limits are exactly that, set individually
for individual users.  In an enviroment like this (again, mine)
am I to set CHILD_MAX to the maximum number of processes that
any user may may have running (which would be the same as PROC_MAX,
as userid == 0 may run this many, and as such would be a meaningless
value), or should I set it to the mininum value that any user
will ever have for the maximum number of process permitted to be
running (for some users, that will be 1 [aside: I can give
entirely reasonable justifications for this limit - for some
userids who do not represent humans], again making the constant useless.
I could set it to an arbitrary approximate value - one that
applies to many, or most, users, but that hardly seems satisfactory
either.

So, I recommend doing away with this constant from <limits.h>,
which is not to say that implementations may not impose such
a limit, merely that attempting to specify the value of the
limit as a system wide constant is not reasonable.

[ I think the justification for CHILD_MAX was that some
implementations do have such a limit (for UIDs other than 0),
and they wanted to guarantee a "minimum limit" of 4 offspring.
Your argument against CHILD_MAX is a good one, though.
For more general objections to <limits.h>, see farther on..
-Gwyn ]

Robert Elz        seismo!munnari!kre    [e-mail]

[ Note that the X3J11 draft has the same problems as the P1003 draft,
since they have many of the same constants defined, and where that is so,
they have the same definitions (I think P1003 got them from X3J11).
X3J11 has a copy of the original mail items through Don Kretsch.  -jsq ]

Volume-Number: Volume 3, Number 7

From jsq  Fri Nov  8 20:39:46 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: fork(), EAGAIN, and CHILD_MAX
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:39:37 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 68
Approved: [e-mail]
Draft-9: 2.9 3.1.1

Date: 06 Oct 85 18:53:44 +1000 (Sun)
>From: Robert Elz <munnari![e-mail]>

In section 2.3 [ of Draft 4; Section 2.4 of Draft 5 -jsq ],
EAGAIN is defined as "Resource temporarily unavailable".
The third sentence of its description states...

    This is a temporary condition and later calls to the
    same routine may complete normally.

It is not abundently clear whether this sentence qualifies only
the preceding one (about read/write with O_NDELAY) or both of
the earlier sentences (the first refers to fork).

[ This has been fixed in Draft 5 by moving the sentence to the
beginning of the paragraph. -Gwyn ]

In section 3.1, and also in the the first sentence of the description
referred to above, fork() is stated to return EAGAIN if either
the system process table is full (PROC_MAX would be exceeded), or
if the limit on the number of processes runnable by a single userid
(CHILD_MAX) would be exceeded.

I submit that these conditions represent two distinct errors, which
should not be lumped together - in most cases proper handling of a
process table full is to wait a while, and try again (my exact
interpretation of "Resource temporarily unavailable").  However,
in most cases, this is a fruitless exercise if the user has exceeded
the number of processes he is permitted - only killing one of the
user's running processes will usually have much effect (it is
possible that there are background processes, which may soon terminate,
but this would seem to be the exception, rather than the rule).
The process to kill when a fork fails because of the user having
too many running processes is logically the parent process, the
one attempting to fork().

[ Processes can terminate for other reasons, such as completion
of their assigned tasks, in which case trying fork() again may
eventually succeed.  The wording of the Draft ("may") seems to
be such that the programmer is never guaranteed that the
resource in question will ever become available. -Gwyn ]

[ For those of you who are not aware of it, the words "shall,"
"should" and "may" are magic words with very specific meanings
which are mandated by IEEE for standards of this kind.  See
Section 1.2 of Draft 5 for the precise definitions.  This
particular point about fork has been discussed in the committee
before, and the word "may" was chosen carefully.  -jsq ]

So, I would suggest adding a new error code, I call it EPROCLIM
(4.2 sites should find it already defined in their <errno.h> files!)
and having fork() return this if the error is that the user's
process limit is reached.

I know that this is incompatible with many (all, except mine)
kernel implementations, however, I think that can easily be
rectified by making it clear that EPROCLIM and EAGAIN may
be the same value.

I think this is a suitable compromise that enables sensible
forward growth, while not damaging backwards portability.

[ That is a sensible suggestion, but since it is not the way
current systems work it may be hard to get a consensus on it. -Gwyn ]

Robert Elz        seismo!munnari!kre    [e-mail]

Volume-Number: Volume 3, Number 8

From jsq  Fri Nov  8 20:40:08 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Does EFAULT still make sense as an error return?
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:40:03 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 87
Approved: [e-mail]
Draft-9: EFAULT

Date: 06 Oct 85 18:54:15 +1000 (Sun)
>From: Robert Elz <munnari![e-mail]>

I notice that P1003 has gone to a lot of trouble (I refer to draft 4)
to specift that EFAULT is a possible error return from every system
call that takes a pointer as one of its arguments (or if there are
any that were missed, I missed them too!)

I have yet to see an implementation that will actually return EFAULT
in many of those instances - consider "time()", "wait()", and "pipe()".

[ System V Release 2 claims to return EFAULT in most of these
cases, including time() and wait().  (I don't know if it really
does.)  Clearly this is what one would want to have happen.
If a signal occurred instead, and the user signal catcher
returned normally, how would one then complete the system
call?  Surely not by returning EINTR :-)  -Gwyn ]

In each of those, the system call definition specifies that a pointer
to a data structure of one type or another is an argument.  However,
all implementatins that I am aware of do not actually pass the pointer
across the user/kernel interface, preferring rather the obtain the
returned value via some system defined internal mechanism, and have the
user interface routine actually store it in the data structure the
user intended.

If such an implementation is required to return EFAULT rather than
send a signal to the process, much extra work is going to be involved.
Since (probably) all implementations are involved here, it seems to
me that things should be relaxed here.

[ Agreed.  -Kretsch ]

[ Isn't u.u_error available for the copyout() code?  Setting it
to EFAULT instead of posting a signal seems a trivial change.  -Gwyn ]

I would add the following sentence to the definition of EFAULT in
section 2.3 [ of Draft 4; Section 2.4 of Draft 5 -jsq ]:

    This condition may generate a signal; the error is returned
    if the signal is not generated, or is ignored.

[ I'm not sure this is the proper action.  This may cause currently
working programs to break.  -Kretsch ]

This closely follows the wording of the similar condition with EPIPE,
except that it allows implementations to decide in which cases they
will send a signal, and in which cases they will return EFAULT.

[ This may turn out to be a good compromise solution.  -Gwyn ]

I would actually prefer if new kernel implementations could dispense
with EFAULT entirely, and send a SIGSEGV instead (returning EFAULT
only if the signal is ignored).

This would greatly help to blur the distinction between what is
a "system call" and what is a "library routine".

It seems to me, that now the time has come when most of us no longer
write code in assembler, this distinction is outdated.  To me,
a "system call" and a "library routine" look just the same.

If the kernel sent a signal whenever it detected an illegal address
in an argument provided by a user to a system call, then system
calls would behave just like library routines, and it would be
much easier for an implementation to choose how to implement
any particular function.  For example, on some systems, it may
be desirable to implement "uname()" as a library routine that reads
a file - to allow the data returned to be easily changed by
the site administrators.  This is not going to be easy to do
if uname() is constrained to return EFAULT and not send a SIGSEGV.

[ Indeed, one of the silliest parts of emulating system calls
with library routines (as in my System V emulation for 4.2BSD)
is the attempt to return EFAULT instead of causing a SIGSEGV.

What you say is quite right, but it would be a significant change
from the System V baseline so I suspect we would not arrive at a
consensus in favor of the SIGSEGV approach.

Draft 5 Appendix A.7 specifically mentions problems with EFAULT
and solicits suggestions for incorporation into the "final use"
standard.  -Gwyn ]

Robert Elz        seismo!munnari!kre   [e-mail]

Volume-Number: Volume 3, Number 9

From jsq  Fri Nov  8 20:40:34 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:40:27 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 100
Approved: [e-mail]
Draft-9: 2.9

Date: 06 Oct 85 18:36:07 +1000 (Sun)
>From: Robert Elz <munnari![e-mail]>

Section 2.7 of P1003 draft 4 [ Section 2.8 of Draft 5 -jsq ]
requires that implementations must define values of certain
constants in <limits.h>.

One of the required constants is OPEN_MAX, the maximum number
of files that one process can have open at any given time.

The problem I see with this limit is quite different than
that I perceive with CHILD_MAX (mentioned in a previous mail
item), though the problems there could apply here as well,
a per process limit is just a special case of a per user limit.
Which is to say, that there is no guarantee that this limit
will be a constant across users.

With OPEN_MAX though, there is another problem.  Defining this
as a constant will lead application programs to reference it.
(If these constants are not intended to be referenced, then that
should be clearly stated, in which case I will wonder what the
intention of them is).

[ I think they are intended to be referenced by C code
(in most cases).  -Gwyn ]

The problem here, is that this makes binary compatability of
application processes across system generations hard to
achieve.  That is, generating a new binary kernel image
may require recompiling large numbers of application programs,
without any particularly good cause.

[ Agreed, but binary compatibility is not a goal of this standard.
-Kretsch ]

[ Applications intended to be ported in binary form would
have to restrict themselves to the minimum possible sizes
for those things that can vary from system to system.
This would entail a special <limits.h> on the development
system.  Is this really a problem?  (Non-rhetorical question.)
-Gwyn ]

This applies to many (if not almost all) of the constants defined in
section 2.7 [ 2.8 of D5 -jsq ], I have singled OPEN_MAX out for
attention, as it is one that I can see some implementations changing
regularly.  Occasionally an application appears that really needs a
large value for OPEN_MAX to be effecient.  If that application is
important enough, a site may want to increase the limit.  As long as
this means no more than a system generation, and reboot, it is a
practicable task, however if all, or most of the user-mode binaries
need to be rebuilt, it becomes close to impossible.

[ Seems to me only those critical binaries (/etc/init?)
that wanted a huge OPEN_MAX would need to be rebuilt.  -Gwyn ]

I suggest deleting all of the constants, and instead specifying
a library routine, which when handed a name defined in <limits.h>
will return the associated constant.

[ A la getenv() - sounds reasonable to me.  X3J11 only deals with
a single process mmodule so they haven't considered different
values of these limits for different users/processes.  Maybe
P1003 should!  -Kretsch ]

It may be that for various reasons a few of the limits really
deserve to remain constants (the ones that specify characteristics
of the hardware may be candisates), but most of these "constants"
are really no more than transitory constants, and should not
be wired in anywhere.

A simplistic implementation of the function would simply
index an array by its argument, and return the number found.
This results in building the constants into the binaries
just as the current scheme - but it also discourages their
use in places where constants are "required" by the C standards,
making any application that does this non-portable to an
implementation where these "constants" are true variables.

Other implementations may involve reading a file, or
performing system calls.  The mechanism is not important.

[ Unfortunately, OPEN_MAX is one very likely candidate for
use as a C integer constant (such as defining the size of
an array of file status flags).

<limits.h> has been the subject of much debate, for the reasons
you give and for others.  I think we really want to have minimum
guaranteed limits on things, and really want to have C constants.

Attempting to change to a different mechanism at this point
would probably delay balloting on the "trial use" standard.
This seems like a good topic to bring up when critiquing the
trial use standard, so that an acceptable solution could be
built into the final use standard.  Perhaps feedback on this
should be solicited in Appendix A.
-Gwyn ]

Robert Elz        seismo!munnari!kre    [e-mail]

Volume-Number: Volume 3, Number 10

From jsq  Fri Nov  8 20:40:58 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003/D4 editorial comments
Message-Id: <[e-mail]>
Date: 9 Nov 85 02:40:51 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 62
Approved: [e-mail]
Draft-9: 8.4

Date: 06 Oct 85 20:21:37 +1000 (Sun)
>From: Robert Elz <munnari![e-mail]>

Section 2.4 [ of Draft 4; Section 2.5 of Draft 5 -jsq ]
terminates with a sentence that does not belong,
there are no structures mentioned anywhere in this section.

[ I previously reported that this had been fixed by removing
the sentence.  In fact the change Doug mentions below was done.  -jsq ]

[ This sentence was changed in Draft 5 to say that all TYPES
defined in this file SHOULD have type names ending with _t.  -Gwyn ]

Several sections (eg: 3.3.2.6) indicate that longjmp is defined
in the X3J11 C language standard.  It is also defined in
section 6.  This seems to be one function that clearly belongs
in the C standard, I would delete section 6 completely.
(Currently it makes reference to "auto" and "register" "storage classes"
none of which terms seem to be defined anywhere, or within the
scope of this standard).  Deleting section 6 would also get rid
of the most objectionable (and unnecessary) sentence...
    However longjmp shall never cause setjmp
    to return a value of 0.
At best a caution that some implementations may not allow setjmp
to return 0 when called from longjmp would be called for.

[ The offending section was removed for Draft 5.  -Gwyn ]

[ In general, anything which is C and not UNIX has been removed
from P1003 and replaced with pointers to X3J11.  I posted a
detailed synopsis of these sorts of changes a couple of months
ago.  -jsq ]

Section 4.5.2 seems to be largely repeated in section 4.5.3.2.
The former should probably simply be deleted.

[ Draft 5 has instead uniformly defined data structures like
this at the beginning of subsections and omitted them from
the individual routines.  It also has put #defined constants
into tabular form instead of mock C code.  -Gwyn ]

Apart from minor glitches like these, I must complement the
editors, it is obvious that much thought has gone into wording
this draft in a manner that will result in just the results
desired.  Congratulations.

[ Draft 5 appears at first reading to be substantially better
organized than Draft 4 and also technically improved.  I
have only a few relatively minor quibbles with it as it now
stands, apart from the absence of a termio specification.
-Gwyn ]

[ Termio was a topic of much discussion at the D.C. meeting.
The former draft currently appears in an Appendix, with a pointer
to it from the text of the draft, saying in effect that P1003
intends to have such a section in the final draft, but it
was not possible to agree on that particular section draft
in time for Trial Use.  -jsq ]

Robert Elz        seismo!munnari!kre    [e-mail]

Volume-Number: Volume 3, Number 11

From jsq  Mon Nov 11 18:05:57 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Is SIGILL omitted from the list of "hardware" signals for good reason?
Message-Id: <[e-mail]>
Date: 12 Nov 85 00:05:51 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 19
Approved: [e-mail]
Draft-9: 3.3.1

Date: Sun, 10 Nov 85 16:04:35 PST
From: mordor!lll-crg!sun!guy (Guy Harris)

> Was this deliberately omitted - in which case I object, as
> a SIGILL is quite likely the best choice for SIGABRT...

Not necessarily; 4.xBSD happened to choose it for the VAX, because there's
no IOT instruction, but VAX S5's "abort" routine is a (portable!) piece of C
code which does

    kill(getpid(), SIGIOT);

(and also flushes all the Standard I/O buffers beforehand).  SIGIOT is
pretty useless except on PDP-11s; the S5 shell says "abort - core dumped"
rather than "IOT trap - core dumped" when a process gets a SIGIOT.

I think 4.xBSD should adopt S5's "abort" routine.

Volume-Number: Volume 3, Number 12

From jsq  Mon Nov 11 18:06:31 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 12 Nov 85 00:06:24 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 19
Approved: [e-mail]
Draft-9: 2.9

Date: Sun, 10 Nov 85 16:26:26 PST
From: mordor!lll-crg!sun!guy (Guy Harris)

> [ Seems to me only those critical binaries (/etc/init?)
> that wanted a huge OPEN_MAX would need to be rebuilt.  -Gwyn ]

Nope.  What about programs like shells which want to close every single open
file descriptor?  If OPEN_MAX were a compile-time constant, these programs
would have to be recompiled if you just bought Keg-O-Data's new DBMS which
requires 100 open file descriptors and reconfigured your kernel to up the
max-file-descriptors-per-process limit.

> I suggest deleting all of the constants, and instead specifying
> a library routine...

Yes, and *please* call the one for OPEN_MAX "getdtablesize", so 4.2 programs
won't have to change.

Volume-Number: Volume 3, Number 13

From jsq  Mon Nov 11 18:07:06 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: OPEN_MAX and CHILD_MAX
Message-Id: <[e-mail]>
Date: 12 Nov 85 00:06:57 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 20
Approved: [e-mail]
Draft-9: 2.9

>From seismo!gatech!akgua!whuxlm!vilya!am Mon Nov 11 12:34:18 1985
Date: Mon, 11 Nov 85 11:40:54 est
Status: O

John,
    I believe that both OPEN_MAX and CHILD_MAX are useful as constants
available to the programmer to protect against running out of children
or files. Use of them in a non-controlled way will, of course, require
unnecessary re-compilations when system limits are changed. Let them be
in the standard and caveat emptor.
    Maybe there should be separate limits.h files, eg hardlimits.h
for things which will never (   :-)  ) change on a given system, such as
hardware limits (32-bit etc.) and a softlimits.h file which contains
current limits which change when system parameters are updated etc. This
will avoid many unnecessary recompilations when the program does not use
the softlimits.
    Avi Malek (vilya!am    @ATT-Bell Labs, Parsippany NJ)
---
Avi Malek @ATT Bell Labs Parsippany, NJ

Volume-Number: Volume 3, Number 14

From jsq  Mon Nov 11 18:07:36 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Does EFAULT still make sense as an error return?
Message-Id: <[e-mail]>
Date: 12 Nov 85 00:07:30 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 58
Approved: [e-mail]
Draft-9: EFAULT

Date: Sun, 10 Nov 85 16:19:03 PST
From: mordor!lll-crg!sun!guy (Guy Harris)

> [ System V Release 2 claims to return EFAULT in most of these
> cases, including time() and wait().  (I don't know if it really
> does.)  Clearly this is what one would want to have happen.
> If a signal occurred instead, and the user signal catcher
> returned normally, how would one then complete the system
> call?  Surely not by returning EINTR :-)  -Gwyn ]

Normally, one wouldn't *want* to complete the system call in this case; how
do you complete a call to "time" where the pointer points into some
nonexistent or non-writable location?  The only case where this would be
useful is in something like (aargh) the Bourne shell, where the signal
catcher would grow the data space to make that pointer valid.  This would
only work with 4.xBSD-style restartable system calls; the system call should
*not* be completed, but re-executed.

> [ Isn't u.u_error available for the copyout() code?  Setting it
> to EFAULT instead of posting a signal seems a trivial change.  -Gwyn ]

"copyout" isn't being used here; the copying of the data from the registers
it's usually returned in (for calls like "wait", "time", and "pipe") into
the location pointed to by the argument to the system call is done by
user-mode code, and it'd have to catch SIGSEGV in order to make the system
call return EFAULT in that particular case (oh yes, and in the cases of
"wait" and "pipe", you couldn't re-execute the call).

> I would add the following sentence to the definition of EFAULT in
> section 2.3 [ of Draft 4; Section 2.4 of Draft 5 -jsq ]:

>     This condition may generate a signal; the error is returned
>     if the signal is not generated, or is ignored.

> [ I'm not sure this is the proper action.  This may cause currently
> working programs to break.  -Kretsch ]

1) The P1003 standard *already* breaks currently working programs; no UNIX
which is currently available returns -1 and sets "errno" to EAGAIN on
no-delay reads or writes - either it returns 0 (S3, S5) or returns -1 and
sets "errno" to EWOULDBLOCK.

2) It's not clear that *reasonable* existing programs would be broken - what
can you do with an EFAULT except print an error message and exit?  Getting a
SIGSEGV would do both of the above, at least with a reasonable parent
process (like a shell), and would have the added advantage of giving you a
core dump so you can debug the problem more easily (if a system call gets
EFAULT, there is buggy code somewhere).

> I would actually prefer if new kernel implementations could dispense
> with EFAULT entirely, and send a SIGSEGV instead (returning EFAULT
> only if the signal is ignored).

YES.  V6 (!) did this; EFAULT was added subsequent to the release of V6, and
appeared in PWB/UNIX 1.0, V7, and its successors (4.xBSD, S3, S5, ...).  I
am at a loss to figure out why this was done.

Volume-Number: Volume 3, Number 15

From jsq  Tue Nov 12 21:36:10 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: EFAULT and limits
Message-Id: <[e-mail]>
Date: 13 Nov 85 03:35:54 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 30
Approved: [e-mail]
Draft-9: 2.9 EFAULT

Date:     Mon, 11 Nov 85 11:53:25 EST
From: Dan Franklin <[e-mail]>

Re EFAULT from time(), etc.: The System V Interface Definition says (p. 136)
that "time will fail and its actions are undefined if tloc points to an
invalid address" as opposed to other system calls where the SVID explicitly
says they will return EFAULT.  So it seems that it would not be deviating too
much from AT&T's Unix line to permit some system calls to get SIGSEGV given
an invalid pointer.  It certainly seems the most sensible course to me.

I suspect that the discrepancy between the SVID and the SVr2 manual occurs
because the SVr2 code doesn't implement what the SVr2 manual says, and the
SVID makes SVr2's behavior legitimate.

Re limits: it really is much more sensible to determine the limits in a way
which permits a vendor to supply them at run time rather than compile time.
While I don't want to get into an argument over whether the standard ought to
address binary compatibility or not, it seems to me that it should certainly
not PRECLUDE a vendor from offering binary compatibility across changes in
some system "constants".  OPEN_MAX is a particularly good example of a
"constant" that is likely to change over the next few years; I know of several
database-producing groups that can't stand the limit of 20 open descriptors,
and it's not particularly wonderful for the project I'm on now, either.
It is true that this will mean that (e.g.) an array of flags will have to be
allocated dynamically rather than statically if it is to be done correctly;
I don't see this as a serious disadvantage.

    Dan Franklin

Volume-Number: Volume 3, Number 16

From jsq  Wed Nov 13 22:17:12 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 14 Nov 85 04:17:05 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 29
Approved: [e-mail]
Draft-9: 2.9

Date: Wed, 13 Nov 85 17:02:39 est
From: Kee Hinckley <harvard!wanginst!apollo!nazgul>

In article <[e-mail]> you write:
> Date: 06 Oct 85 18:36:07 +1000 (Sun)
> >From: Robert Elz <munnari![e-mail]>
...
> I suggest deleting all of the constants, and instead specifying
> a library routine, which when handed a name defined in <limits.h>
> will return the associated constant.
>

One problem with this is that a piece of code may want to #if off of
particular constants.  For instance, if I discover that the amount
of memory I have is too small, and I don't have virtual memory then
I might want to use temporary files.  This could be all handled
automatically by using #if's in the code if I could reference a
constant, but it would not work out nearly as well if I had to
make that kind of decision at runtime.  I tend to agree with the
other responses.  The problems that are introduced by limits.h
almost all relate to binary portability, and binary portability
is not a concern for the standard.

                                       Kee Hinckley
                                       User Environment
                                       Apollo Computer
                                       ...decvax!wanginst!apollo!nazgul

Volume-Number: Volume 3, Number 17

From jsq  Fri Nov 15 07:06:49 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits
Message-Id: <[e-mail]>
Date: 15 Nov 85 13:06:41 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 22
Approved: [e-mail]
Draft-9: 2.9

>From seismo!philabs!flkvax!trwrb!desint!geoff (Geoff Kuenning)
Date: Thu, 14 Nov 85 23:47:29 GMT

I support the idea of making the limits available at run-time, but
let's not copy Berkeley's naming (getdlimit or whatever it is).  There
should be just *one* call that gets all the limits into a struct;
Berkeley compatability can be achieved with "wrapper" routines.

UniSoft has already done 90% of the work of this call by moving
everything that used to be in param.h into a structure named 'v'.  This
was done so that binary customers could patch NPROC et al easily, but a
system call that returned the contents of 'v' would be trivial to add.
Maybe we could get AT&T to buy the changes (they're extensive) from UniSoft.

[ 3B20 System V Release 2 has this, so maybe they did.
Personally, I don't like it.  -mod ]
--

    Geoff Kuenning
    {hplabs,ihnp4}!trwrb!desint!geoff

Volume-Number: Volume 3, Number 18

From jsq  Fri Nov 15 07:10:25 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 15 Nov 85 13:10:14 GMT
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 36
Approved: [e-mail]
Draft-9: 2.9

Date: Thu, 14 Nov 85 17:21:36 pst
From: saber![e-mail] (Mark Callow)

> From: Kee Hinckley <harvard!wanginst!apollo!nazgul>
>
> In article <[e-mail]> you write:
> > Date: 06 Oct 85 18:36:07 +1000 (Sun)
> > >From: Robert Elz <munnari![e-mail]>
> ...
> > I suggest deleting all of the constants, and instead specifying
> > a library routine, which when handed a name defined in <limits.h>
> > will return the associated constant.
> >
>
> One problem with this is that a piece of code may want to #if off of
> particular constants.  For instance, if I discover that the amount
> of memory I have is too small, and I don't have virtual memory then
> I might want to use temporary files.
You can do this just as well with an if statement at runtime.  Then
if someone decides to add more memory to their machine they don't
have to recompile their world to take advantage of it.

> ...but it would not work out nearly as well if I had to
> make that kind of decision at runtime.
Why not?  The penalty is a small increase in the size of the
binary.

limits.h and all similar kinds of wired-in constants are the pits.
What happens in a network environment?  Do your servers have one
copy of the program for each client configuration?  Of course not.
What does a computer manufacturer do?  Have a different software
release for each system configuration?  Of course not.  You
either end up in the least common denominator trap or you ignore
limits.h and implement the library function suggested by kre.

Volume-Number: Volume 3, Number 19

From jsq  Fri Nov 15 18:34:46 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: limits.h
Message-Id: <[e-mail]>
Date: 16 Nov 85 00:34:39 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 21
Approved: [e-mail]
Draft-9: 2.9

Date: Fri, 15 Nov 85 00:48:36 cst
From: allegra!jpl (John P. Linderman)

I agree that values like OPEN_MAX that may well vary among binary
compatible machines should be determinable at execution time.  It
makes a lot of sense to have a routine that would look them up in
the copy of limits.h on the runtime machine.  If the file were
missing (or otherwise unusable), default values could be compiled
in from the copy of limits.h on the compile-time machine.  This
would leave us with sensible defaults, even on a bare-bones machine,
and a high level of compatibility across binary compatible machines,
regardless of the machine a source was compiled on.

I don't imagine people will bury these lookups deep in nested loops,
so efficiency shouldn't be much of an issue.  A lookup that invoked
cpp would be easy to write and would guarantee compatibility with
compile-time lookups.

John P. Linderman  allegra!jpl

Volume-Number: Volume 3, Number 20

From jsq  Fri Nov 15 18:37:06 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  limits
Message-Id: <[e-mail]>
Date: 16 Nov 85 00:37:00 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 30
Approved: [e-mail]
Draft-9: 2.9

Date:     Fri, 15 Nov 85 11:10:55 EST
From: Dan Franklin <[e-mail]>

> ... There
> should be just *one* call that gets all the limits into a struct;
> Berkeley compatability can be achieved with "wrapper" routines.

I agree that there should be one system call, but not this one.  This one means
that if a manufacturer wants to add a limit in a later version of the system
(either in response to a change to the standard, or to enhance his system) it's
once again necessary to recompile everything that might use the system call, in
order to be able to return the larger structure.  You can solve this problem by
defining the system call to take a pointer and a length, rather than just a
pointer; then the only time recompilation is necessary is if a limit is deleted
(and you want to reclaim the structure element).  But why should it be
necessary at all?

Instead of one system call which returns *everything*, there should be one
system call which takes a numeric index "naming" the limit to be returned.  An
index of 0 would return the total number of limits. Limits.h would give the
indices.

Letting the system call "know" what limit you're actually interested in also
permits (in theory) programs to be monitored (in the kernel) to see what limits
they are requesting, so that you can know ahead of time what programs would
benefit from changing what parameters.

    Dan

Volume-Number: Volume 3, Number 21

From jsq  Fri Nov 15 18:38:22 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Limits that can stay in limits.h
Message-Id: <[e-mail]>
Date: 16 Nov 85 00:38:17 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 38
Approved: [e-mail]
Draft-9: 2.9

Date:     Fri, 15 Nov 85 11:49:49 EST
From: Dan Franklin <[e-mail]>

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

From jsq  Fri Nov 15 18:43:19 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Draft ambiguity
Message-Id: <[e-mail]>
Date: 16 Nov 85 00:43:07 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 18
Approved: [e-mail]
Draft-9: 2.9

Date:     Fri, 15 Nov 85 11:53:55 EST
From: Dan Franklin <[e-mail]>

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

From jsq  Sat Nov 16 16:28:11 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits.h
Message-Id: <[e-mail]>
Date: 16 Nov 85 22:28:04 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 466
Approved: [e-mail]
Draft-9: 2.9

[ Everybody talks about it, but this one did something about it.  -mod ]

Date: Sat, 16 Nov 85 15:11:46 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)

Reading in limits on a per-machine basis is a good idea.
However, the idea of reading in a struct or using a numerical
ID for limits both constrain expandability.  I also have
problems with reading directly from limits.h.  Let's do it
from a file like /etc/limits.

By the way -- one person said that define'd limits were needed
for #if expressions in code.  What about if () expressions?  The
only case in which the former couldn't be handled by the latter is
in the case that you are really squeezed for core.  ("main memory"
to all you young whippersnappers.)

/* #include <local.h> */

/*********************************************************************\
**
** limits -- read limits from the limits file.
**
** Copyright and disclaimers:
**    This code is Copyright (c) 1985 by one or more of:
**        The author named below;
**        The author's institution named below;
**        (No institution paid for this code, so that's it).
**    Permission is hereby granted to use or copy this code, in
**    whole or in part, only under the conditions that this copyright
**    notice (including other portions of this header comment and
**    code herein referenced) are retained with all parts of this
**    code; that all changes or corrections to this code be fully
**    annotated in the code and notification of such be sent to
**    the author and authors institution; and that this code not
**    specifically be used for profit (although it may be included
**    to enhance a larger work which would otherwise have still
**    been used for profit).
**
** Syntax:
**    setlimits(filename)
**      char *filename;
**    getlimit(name, buf, length)
**      char *name;    int buf[], length;
**    endlimits()
**
** Description:
**    This is an implementation of the suggested code to read the
**    per-machine limits from a limits file.  It assumes a file of
**    the format:
**        limit-name    limit-value[, limit_value ... ]
**    e.g.:
**        char_bit    8
**        char_min    -128
**        char_max    128
**    etc.  Lines that start with '#' are assumed to be comment
**    lines.  Lines that start with white space are assumed to
**    be continuation lines.
**
**    Setlimits() returns SUCCESS if the file whose name is passed
**    is readable, FAILURE if not.  On a SUCCESS return, the file is
**    set but not opened.  A NULL argument returns to the original
**    file name.  Getlimit() returns FAILURE if no value, otherwise
**    the number of values available.  (May be > length.)
**    Endlimits() closes the limits file, if open.  No value is
**    returned.
**
#ifdef    SCCS
** Last modifed %G% %U%.  Last retrieved %H% %T%.
#endif    SCCS
**
** Author:
**    Joseph S. D. Yao
**    Engineering and Information Sciences Division
**    Hadron, Inc.
**    9990 Lee Highway
**    Fairfax VA   22030
**    [phone]
**
** Routines:
**    int setlimits(filename)
**    int getlimit(name, buf, length)
**    void endlimits()
**    static int getnum(str)
**
** Declared:
**    static char limfile[] = "/etc/limits"
**    static char *curlimfile = limfile
**    static FILE *limf = (FILE *) NULL
**
\*********************************************************************/

#ifndef    lint
# ifdef SCCS
  static char SCCS_id[] = "%W%";
#  else
  static char RCS_id[] =
    "@(#)$Header:$";
# endif    SCCS
#endif    lint

#include <stdio.h>
#include <ctype.h>
#ifdef    limits
# include <limits.h>
#endif    limits
#include <sys/types.h>

/* #include "std.h" */
#define TRUE    1
#define FALSE    0

#define SUCCESS    0
#define FAILURE    (-1)

#define NUL    '\0'

#define STDIN    0
#define STDOUT    1
#define STDERR    2

#define ROPEN    0
#define WOPEN    1
#define RWOPEN    2
#define XOPEN    3
#define RXOPEN    4
#define WXOPEN    5
#define RWXOPEN    6

#define READ    "r"
#define WRITE    "w"
#define APPEND    "a"
#define WREAD    "r+"
#define RWRITE    "w+"
#define RAPPEND    "a+"

#define F_ACC    00
#define X_ACC    01
#define W_ACC    02
#define R_ACC    04

#define ever        (;;)
#define until(x)    while (!(x))
#define unless(x)    if (!(x))

#define streq(a,b)    (strcmp(a, b) == 0)
#define strneq(a,b,n)    (strncmp(a, b, n) == 0)

typedef char bool;    /* Smallest data object */
typedef int boolean;    /* Function argument and return. */
/**/

#define NL    '\n'
#define COMMENT    '#'
#define COMMA    ','
#define PLUS    '+'
#define MINUS    '-'

static char limfile[] = "/etc/limits";
static char *curlimfile = limfile;

static FILE *limf = (FILE *) NULL;

/*
** Setlimits() returns SUCCESS if the file whose name is passed
** is readable, FAILURE if not.  On a SUCCESS return, the file is
** set but not opened.  A NULL argument returns to the original
** file name, whether or not the original file is readable.
** Note that a non-NULL filename must not disappear (e.g., be
** reclaimed on the stack, free'd, or written over) before it
** is opened in getlimit()!
*/
int setlimits(filename)
  char *filename;    /* NULL or the name of the new limits file. */
{
    void endlimits();

    /* If name is NULL, go to the original. */
    if (filename == (char *) NULL) {
        if (limf != NULL)
            endlimits();
        curlimfile = limfile;
        return(SUCCESS);
    }

    /* If new file can't be read, forget it. */
    if (access(filename, R_ACC) < 0)
        return(FAILURE);

    /* Close old open file. */
    if (limf != NULL)
        endlimits();
    /* And use new one. */
    curlimfile = filename;
    return(SUCCESS);
}

/*
** Getlimit() returns FAILURE if no value, otherwise the number
** of values available.  The number of values may be > 'length';
** but the number stored into buf[] will never be.
** Note that the result is always returned as a number of integers.
** It is up to the calling program to put them together into longs,
** complexes, etc. or decompose them into chars, bitfields, or
** whatever.
**
** The search starts from wherever it left off, which improves
** performance if names are called in order from the file.
** (Say, alphabetical order.)
*/
int getlimit(name, buf, length)
  char *name;    /* Name of the limit wanted. */
  int buf[];    /* Pointer to the array of int's for these values. */
  int length;
{
    register char *cp;
    register int n;
    bool been_here;
    bool new_line;
    char inbuf[BUFSIZ];
    off_t current;
    extern char *index();

    /* If not open, open it. */
    if (limf == (FILE *) NULL)
        limf = fopen(curlimfile, READ);

    /* If still not open, kick it in. */
    if (limf == (FILE *) NULL)
        return(FAILURE);

    n = strlen(name);
    /* Find where we currently are in the file. */
    current = ftell(limf);
    /* Initialise boolean values. */
    new_line = TRUE;
    been_here = FALSE;

    /* Search, starting wherever we left off. */
    for ever {
        /* Get a line from the file */
        cp = fgets(inbuf, sizeof(inbuf), limf);
        if (cp != (char *) NULL) {

            /* If gotten, test: if start of line */
            if (new_line &&
                /* and not a comment line */
                *cp != COMMENT &&
                /* and not a continuation line */
                !isspace(*cp) &&
                /* and the limit name is first */
                strneq(cp, name, n) &&
                /* followed by white space */
                isspace(cp[n]))
                break;    /* go handle it. */

            /* Check whether a NL terminated the read. */
            new_line = (index(cp, NL) != (char *) NULL);
        } else {
            /* If not gotten, re-cycle. */

            /*
            ** Make sure the file doesn't get changed
            ** and cause an infinite loop here.
            */
            if (been_here)
                return(FAILURE);
            been_here = TRUE;

            /* Go back. */
            (void) fseek(limf, (off_t) 0L, 0);
            /* Well this starts a new line, no? */
            new_line = TRUE;
        }

        /* If we're where we started, we failed. */
        if (current == ftell(limf))
            return(FAILURE);
    }

    /*
    ** We only get here if we have a line in inbuf (or the start
    ** of one) that contains the limit name.  Skip over it and
    ** start passing values.
    */
    cp += n + 1;
    n = 0;
    /* Check whether a NL terminated the read. */
    new_line = (index(cp, NL) != (char *) NULL);

    /*
    ** Our value may be preceded by whitespace, and is ended
    ** by a comma or whitespace or comment or EOL.
    */
    for ever {
        /* Skip any initial white space. */
        while (isspace(*cp))
            ++cp;

        /* Check whether line is done. */
        if (*cp == COMMENT || *cp == NUL) {
            /* Save current position */
            current = ftell(limf);
            /* Get new line. */
            cp = fgets(inbuf, sizeof(inbuf), limf);
            /* If EOF, do it over again at loc 0. */
            if (cp == (char *) NULL) {
                (void) fseek(limf, (off_t) 0L, 0);
                current = (off_t) 0L;
                cp = fgets(inbuf, sizeof(inbuf), limf);
                /* There has to be data here. */
                if (cp == (char *) NULL) {
                    /* "never happen" */
                    break;
                }
            }

            /*
            ** If new line is start of line but no white
            ** space, go back to start of line and return.
            */
            if (!new_line || !isspace(*cp)) {
                (void) fseek(limf, current, 0);
                break;
            }

            /* Check whether a NL terminated the read. */
            new_line = (index(cp, NL) != (char *) NULL);

            continue;
        }

        /* If it can fit, store the present value. */
        if (n < length)
            buf[n] = getnum(cp);

        /* Count another value. */
        ++n;

        /*
        ** We want to break but not skip on space, COMMENT, and
        ** NUL.  We want to skip and break on COMMA.  We want
        ** just to skip over everything else.
        */
        while (!isspace(*cp) && *cp != COMMENT && *cp != NUL &&
               *cp++ != COMMA);
    }

    /* Return the number of values found. */
    return(n);
}

/*
** Endlimits() closes the limits file, if open.  No value is
** returned.
*/
void endlimits()
{
    if (limf != (FILE *) NULL) {
        (void) fclose(limf);
        limf = (FILE *) NULL;
    }
}

/*
** This routine converts strings to numbers of base specified
** by 0x or 0 or no prefix.  Signs are allowed.  Atoi() isn't
** used because it doesn't allow different bases, and for the
** sake of consistency.
*/
static int getnum(str)
  register char *str;
{
    register int base = 10;
    register int i = 0, digit;
    register int sign = 1;

    while (isspace(*str) || *str == PLUS || *str == MINUS) {
        if (*str == MINUS)
            sign = -sign;
        ++str;
    }

    if (*str == '0') {
        ++str;
        if (*str == 'x') {
            ++str;
            base = 16;
        } else
            base = 8;
    }

    /*
    ** As opposed to code that assumes contiguous digits and
    ** letters, the following will work even for (*shudder*)
    ** EBCDIC.  Heck, it'll work for TTS and Baudot!
    */
    for ever {
        digit = -1;
        switch (*str++) {
          case '0':    digit = 0; break;
          case '1':    digit = 1; break;
          case '2':    digit = 2; break;
          case '3':    digit = 3; break;
          case '4':    digit = 4; break;
          case '5':    digit = 5; break;
          case '6':    digit = 6; break;
          case '7':    digit = 7; break;

          case '8':    if (base > 8) digit = 8; break;
          case '9':    if (base > 9) digit = 9; break;

          case 'A':
          case 'a':
            if (base > 10)
                digit = 10;
            break;

          case 'B':
          case 'b':
            if (base > 11)
                digit = 11;
            break;

          case 'C':
          case 'c':
            if (base > 12)
                digit = 12;
            break;

          case 'D':
          case 'd':
            if (base > 13)
                digit = 13;
            break;

          case 'E':
          case 'e':
            if (base > 14)
                digit = 14;
            break;

          case 'F':
          case 'f':
            if (base > 15)
                digit = 15;
            break;

          default:    break;
        }

        if (digit < 0)
            break;

        i *= base;
        i += digit;
    }

    if (sign < 0)
        return(-i);
    return(i);
}

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}

Volume-Number: Volume 3, Number 24

From jsq  Tue Nov 19 16:04:21 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 19 Nov 85 22:02:44 GMT
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 13
Approved: [e-mail]
Draft-9: 2.9

Date: Mon, 18 Nov 85 11:13:43 pst
From: seismo!gatech!hplabs!sdcrdcf!scgvaxd!felix!peregrine!mike (Mike Wexler)

I have another argument against the desirability of these constants.  It does
not allow people to do implementations that don't have any limititations(other
than availability of resources)  It would be fairly easy to desing a system
that would allow you to have an "unlimited" number of files, by allocating
a new table when the current table gets full.

Mike Wexler
(trwrb|scgvaxd)!felix!peregrine!mike         [phone]

Volume-Number: Volume 3, Number 25

From jsq  Tue Nov 19 16:40:24 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Draft ambiguity
Message-Id: <[e-mail]>
Date: 19 Nov 85 22:38:31 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 14
Approved: [e-mail]
Draft-9: 2.9

Date: Mon, 18 Nov 85 13:55:26 cst
From: ihnp4!uiucdcs!ccvaxa![e-mail] (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

From jsq  Tue Nov 19 17:46:58 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: limits
Message-Id: <[e-mail]>
Date: 19 Nov 85 23:45:13 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 39
Approved: [e-mail]
Draft-9: 2.9

Date: Mon, 18 Nov 85 13:28:03 cst
From: ihnp4!uiucdcs!ccvaxa![e-mail] (Scott Preece)

> From: Dan Franklin <[e-mail]>
> Instead of one system call which returns *everything*, there should be
> one system call which takes a numeric index "naming" the limit to be
> returned.  An index of 0 would return the total number of limits.
> Limits.h would give the indices.
----------
I'd get rid of the numeric constants part of that, too.  Use a call
like getenv, supplying a name as an Ascii string.

But does this mean we would have to malloc space for anything that
was sized to a system limit (i.e., one could no longer say
    char buf[PATH_MAX]
but would have to do:
    char *buf;
    long bufsize;
    ...
    bufsize = getlimit("PATH_MAX");
    if (bufsize >= 0)
        buf = (char *)malloc(bufsize);
    else
        perror("bufalloc:");
at run time?

Nobody ever said programming had to be easy, but this could
get old pretty quickly...

[ If the limits are taken from <limits.h>, presumably a program could,
if the programmer so chose, #include that file and size arrays at
compile time.  -mod ]

__
scott preece
gould/csd urbana
ihnp4!uiucdcs!ccvaxa!preece

Volume-Number: Volume 3, Number 28

From jsq  Wed Nov 20 12:05:50 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 20 Nov 85 18:05:30 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 20
Approved: [e-mail]
Draft-9: 2.9

From: shell!graffiti!peter (Peter da Silva)
Date: Mon, 18 Nov 85 08:01:43 cst

> > ...but it would not work out nearly as well if I had to
> > make that kind of decision at runtime.
> Why not?  The penalty is a small increase in the size of the
> binary.

For certain architectures, for instance PDP-11 and 8086 small memory
model, that "small increase" may make the difference between having
the program run or not. There have been all too many programs posted
that are "just a little too big" for the PDP-11 to dismiss this
consideration.
--
Name: Peter da Silva
Graphic: `-_-'
UUCP: ...!shell!{graffiti,baylor}!peter
IAEF: ...!kitty!baylor!peter

Volume-Number: Volume 3, Number 29

From jsq  Wed Nov 20 12:14:52 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Draft ambiguity
Message-Id: <[e-mail]>
Date: 20 Nov 85 18:14:44 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 39
Approved: [e-mail]
Draft-9: 2.9

[ 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![e-mail]
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

From jsq  Thu Nov 21 07:22:47 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits
Message-Id: <[e-mail]>
Date: 21 Nov 85 13:22:37 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 25
Approved: [e-mail]
Draft-9: 2.9

Date: Sun, 17 Nov 85 16:28:42 PST
From: seismo!sun!gorodish!guy (Guy Harris)

> I support the idea of making the limits available at run-time, but
> let's not copy Berkeley's naming (getdlimit or whatever it is).  There
> should be just *one* call that gets all the limits into a struct;
> Berkeley compatability can be achieved with "wrapper" routines.

I wanted to make sure nobody introduced a routine to get the size of
the descriptor table with the same semantics as 4.2BSD's, but with a
different name.

> UniSoft has already done 90% of the work of this call by moving
> everything that used to be in param.h into a structure named 'v'.  This
> was done so that binary customers could patch NPROC et al easily, but a
> system call that returned the contents of 'v' would be trivial to add.
> Maybe we could get AT&T to buy the changes (they're extensive) from UniSoft.

You've got it backwards here.  The PWB/UNIX group at AT&T invented
the "v" structure; a lot of PWB/UNIX stuff, including the "v"
structure, made it into UNIX/TS 1.0 and subsequent releases from the
USG/USDL including S3 and S5.  UniSoft already bought that code from
AT&T, so there's no need to get AT&T to buy it back.

Volume-Number: Volume 3, Number 31

From jsq  Thu Nov 21 07:28:26 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits
Message-Id: <[e-mail]>
Date: 21 Nov 85 13:28:19 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 82
Approved: [e-mail]
Draft-9: 2.9

Date: Wed, 20 Nov 85 13:47:00 est
From: seismo!cbpavo.cbosgd.ATT.UUCP!mark (Mark Horton)

After looking at the cc -E / sed approach to reading limits.h, I
wanted to pass along a couple of other ideas.  (There are lots of
UNIX systems out there that don't have C compilers on line, in
particular, both Xenix and the AT&T 3B2 come without them until
you add them in, and they take up enough cash and disk space that
I'll bet many non-hackers won't install them.)

One idea is to do what netnews does to figure out the system name.
I'll enclose the code at the end (the code is public domain)
but basically it opens /usr/include/whoami.h and looks for a line
    #define sysname "whatever"
and extracts the "whatever".  It uses scanf, but hard code could be
written to make this a bit faster and more robust.  It does depend
on the full path name /usr/include/file.h, and it does expect the
#define to be in a reasonably standard format, but these aren't
overly cumbersome restrictions, are they?  (Dare we assume that
/usr/include will be there on all systems, even those without
compilers?)

Another idea is a bit more complex, but solves the "two copies of
the information" problem while still keeping a non-C file like
the proposed /etc/limits.  The idea is to keep a single copy in
/etc/limits, and use the obvious subroutine to get the values for
user code (which then has to malloc things.)  But the kernel has
to know these numbers too, and it's not exactly reasonable for the
kernel to go opening up a user file.  Perhaps a user program can be
written that will read the file, and download it into the kernel
with some kind of (system dependent) magic, such as poking in /dev/kmem,
or a special ioctl, or whatever.  Then the kernel can malloc the
appropriate data structures for the appropriate sizes.

This second idea has a chicken-and-egg problem, in that the data
structures better be allocated EARLY, and the obvious place to do
the downloading is /etc/rc, which is awfully late for such things.
One possibility is for /etc/init to do this before it does much of
anything else, although this is still probably too late (after all,
it has to open the file, and this means the file table has to exist.
Also, it's a process, so the process table must exist.)  One possibility
for handling this is for the kernel to have a very small set of minimal
tables to use until the real numbers come in, at which time it swings
a new pointer to the new tables.  (This is getting pretty ugly, isn't it?)

A third possibility is for the kernel to use the limits.h file, but
for /etc/rc to run a program that reads the values, translates them
into an easily parsed format (possibly binary), and puts these values
into /etc/limits.  Then the hard work is done only once per boot.
This might make it hard to write programs like fsck that run single
user, however.

    Mark

#define HDRFILE "/usr/include/whoami.h"

uname(uptr)
struct utsname *uptr;
{
        char buf[BUFSIZ];
        FILE *fd;

        fd = fopen(HDRFILE, "r");
        if (fd == NULL) {
                fprintf(stderr, "Cannot open %s\n", HDRFILE);
                exit(1);
        }

        for (;;) {      /* each line in the file */
                if (fgets(buf, sizeof buf, fd) == NULL) {
                        fprintf(stderr, "no sysname in %s\n", HDRFILE);
                        fclose(fd);
                        exit(2);
                }
                if (sscanf(buf, "#define sysname \"%[^\"]\"", uptr->nodename) == 1) {
                        fclose(fd);
                        return;
                }
        }
}

Volume-Number: Volume 3, Number 32

From jsq  Thu Nov 21 07:33:24 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: duplicate articles
Message-Id: <[e-mail]>
Date: 21 Nov 85 13:33:15 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 11
Approved: [e-mail]
Draft-9: mod.std.unix

There is a USENET host called bty which is reposting all articles of
mod.std.unix and getting them all wrong, i.e., the From, Organization,
and especially the Message-ID headers are incorrect.  The latter header
is what the news software uses to detect duplicates, so lots of people
are seeing two copies of all articles in this newsgroup.

My attempts to contact bty or their feed, infopro, by mail have failed.
Evidently someone there is reading this newsgroup.  Whoever you are,
please fix this!

Volume-Number: Volume 3, Number 33

From jsq  Fri Nov 22 11:21:46 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits
Message-Id: <[e-mail]>
Date: 22 Nov 85 17:21:39 GMT
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 318
Approved: [e-mail]
Draft-9: 2.9

Date: Fri, 22 Nov 85 04:15:24 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)

One person suggested that having separate <limits.h> and
/etc/limits files might lead to inconsistency.  True.  But
it was a deliberate (and, i apologise, unspoken) design
decision that reading limits.h implied knowing too much
about the machine -- such as how long are longs, what byte
order are ints vs longs vs ... (not to mention floats,
which I completely ignore below, and which I shouldn't!),
and so forth.  Reading a separate file gives me the freedom
to read an n-ary list of ints, formatted God Alone knows
how, which I can convert at my leisure to whatever I want.

Nevertheless, we aim to please, and I made the minor mods
to limits.c to make limits2.c, designed to read a single
int or long int from a define line.  As I said, I completely
ignored floats, which in a working program is unforgivable.
But the person who wants to read in floats may send me
(readable!) code to do so PORTABLY.

The following is a compressed context diff.

*** limits.c    Sat Nov 16 15:08:15 1985
--- limits2.c    Fri Nov 22 00:00:00 1985
***************
*** 66,73
  **    void endlimits()
! **    static int getnum(str)
  **
  ** Declared:
! **    static char limfile[] = "/etc/limits"
! **    static char *curlimfile = limfile
! **    static FILE *limf = (FILE *) NULL
  **
--- 66,75 -----
  **    void endlimits()
! **    static int getnum(str, buf, n)
! **    static int getnbits()
  **
  ** Declared:
! **    static char defn[]    = "#define"
! **    static char limfile[]    = "/etc/limits"
! **    static char *curlimfile    = limfile
! **    static FILE *limf    = (FILE *) NULL
  **
***************
*** 136,138
  #define NL    '\n'
! #define COMMENT    '#'
  #define COMMA    ','
--- 138,141 -----
  #define NL    '\n'
! #define COMM1    '/'
! #define COMM2    '*'
  #define COMMA    ','
***************
*** 141,145

! static char limfile[] = "/etc/limits";
! static char *curlimfile = limfile;

! static FILE *limf = (FILE *) NULL;

--- 144,158 -----

+ #ifdef    EBUG
+ #define WDPLG    2
+ #  else
+ #define WDPLG    (sizeof(long int)/sizeof(int))
+ #endif    EBUG
+
+ typedef char byte;    /* Very small signed value */
+
+ static char defn[]    = "#define";
! static char limfile[]    = "/etc/limits";
! static char *curlimfile    = limfile;

! static FILE *limf    = (FILE *) NULL;

***************
*** 200,201
      register int n;
      bool been_here;
--- 212,214 -----
      register int n;
+     register int defnlen = strlen(defn);
      bool been_here;
***************
*** 204,205
      off_t current;
      extern char *index();
--- 213,219 -----
      off_t current;
+     int getnum();
      extern char *index();
***************
*** 225,240
              if (new_line &&
!                 /* and not a comment line */
!                 *cp != COMMENT &&
!                 /* and not a continuation line */
!                 !isspace(*cp) &&
!                 /* and the limit name is first */
!                 strneq(cp, name, n) &&
!                 /* followed by white space */
!                 isspace(cp[n]))
!                 break;    /* go handle it. */

              /* Check whether a NL terminated the read. */
--- 243,259 -----
              if (new_line &&
!                 /* and starts with "#define" */
!                 strneq(cp, defn, defnlen)) {

+                 /* Skip over defn */
+                 cp += defnlen;
+                 while (isspace(*cp))
+                     ++cp;
+
+                 /* If the limit name is first */
+                 if (strneq(cp, name, n) &&
+                     /* followed by white space */
+                     isspace(cp[n]))
+                     break;    /* go handle it. */
+             }
+
              /* Check whether a NL terminated the read. */
***************
*** 269,334
      cp += n + 1;
-     n = 0;
-     /* Check whether a NL terminated the read. */
-     new_line = (index(cp, NL) != (char *) NULL);

      /*
!     ** Our value may be preceded by whitespace, and is ended
!     ** by a comma or whitespace or comment or EOL.
      */
      for ever {
!         /* Skip any initial white space. */
!         while (isspace(*cp))
              ++cp;
!
!         /* Check whether line is done. */
!         if (*cp == COMMENT || *cp == NUL) {
!             /* Save current position */
!             current = ftell(limf);
!             /* Get new line. */
!             cp = fgets(inbuf, sizeof(inbuf), limf);
!             /* If EOF, do it over again at loc 0. */
!             if (cp == (char *) NULL) {
!                 (void) fseek(limf, (off_t) 0L, 0);
!                 current = (off_t) 0L;
!                 cp = fgets(inbuf, sizeof(inbuf), limf);
!                 /* There has to be data here. */
!                 if (cp == (char *) NULL) {
!                     /* "never happen" */
!                     break;
!                 }
!             }
!
!             /*
!             ** If new line is start of line but no white
!             ** space, go back to start of line and return.
!             */
!             if (!new_line || !isspace(*cp)) {
!                 (void) fseek(limf, current, 0);
!                 break;
!             }
!
!             /* Check whether a NL terminated the read. */
!             new_line = (index(cp, NL) != (char *) NULL);
!
!             continue;
!         }
!
!         /* If it can fit, store the present value. */
!         if (n < length)
!             buf[n] = getnum(cp);
!
!         /* Count another value. */
!         ++n;
!
!         /*
!         ** We want to break but not skip on space, COMMENT, and
!         ** NUL.  We want to skip and break on COMMA.  We want
!         ** just to skip over everything else.
!         */
!         while (!isspace(*cp) && *cp != COMMENT && *cp != NUL &&
!                *cp++ != COMMA);
      }

!     /* Return the number of values found. */
!     return(n);
  }
--- 288,312 -----
      cp += n + 1;

      /*
!     ** Our value may be preceded by whitespace, or a comment.
      */
      for ever {
!         if (isspace(*cp))
              ++cp;
!           else if (*cp == COMM1 && cp[1] == COMM2) {
!             cp += 2;
!             while (*cp != NUL) {
!                 if (*cp++ != COMM2)
!                     continue;
!                 if (*cp == COMM1) {
!                     ++cp;
!                     break;
!                 }
!             }
!         } else
!             break;
      }

!     /* Return the size (number of ints) of values found. */
!     return(getnum(cp, buf, length));
  }
***************
*** 351,361
  ** used because it doesn't allow different bases, and for the
! ** sake of consistency.
  */
! static int getnum(str)
!   register char *str;
  {
      register int base = 10;
!     register int i = 0, digit;
!     register int sign = 1;

      while (isspace(*str) || *str == PLUS || *str == MINUS) {
--- 329,351 -----
  ** used because it doesn't allow different bases, and for the
! ** sake of consistency.  Postfix 'L' or 'l' indicates long.
! **
! ** As long as we're reading in only one (variably sized) value,
! ** we'll also take on the task of storing it.
  */
! static int getnum(str, buf, n)
!   register char *str;        /* String containing number */
!   int *buf;            /* Address of int storage array */
!   int n;            /* Length of storage array */
  {
      register int base = 10;
!     register int j, digit;
!     register long int i = 0;
!     byte sign = 1;
!     bool is_long = FALSE;
!     static int nbits = 0;

+     /* If no room to store, don't bother. */
+     if (n <= 0)
+         return(0);
+
      while (isspace(*str) || *str == PLUS || *str == MINUS) {
***************
*** 430,432
              break;

            default:    break;
--- 420,427 -----
              break;

+           case 'L':    /* Not a digit -- "long" indicator. */
+           case 'l':
+             is_long = TRUE;
+             break;
+
            default:    break;
***************
*** 442,445
      if (sign < 0)
!         return(-i);
!     return(i);
  }
--- 433,470 -----
      if (sign < 0)
!         i = -i;
!
!     buf[0] = i;
!
!     if (!is_long)        /* Value wasn't really long. */
!         return(1);
!
!     if (nbits == 0)        /* Figure out #bits/int */
!         nbits = getnbits();
!
!     if (n > WDPLG)        /* Return only long, at most. */
!         n = WDPLG;
!
!     for (j = 1; j < n; j++) {
!         i >>= nbits;
!         *++buf = i;
!     }
!
!     return(n);
! }
!
! static int getnbits()
! {
!     register int i, n;
!
! #ifdef    EBUG
!     return(16);
! #endif    EBUG
!     n = 0;
!     for (i = 1; i != 0; i <<= 1)
!         ++n;
!     return(n);
  }

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}

Volume-Number: Volume 3, Number 34

From jsq  Fri Nov 22 11:26:51 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: limits ltd.
Message-Id: <[e-mail]>
Date: 22 Nov 85 17:26:40 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 23
Approved: [e-mail]
Draft-9: 2.9

Date: Fri, 22 Nov 85 08:58:04 cst
From: allegra!jpl (John P. Linderman)

It is possible to combine several of the proposed solutions to
run time lookup of symbolic constants.  For example, one might
do the following to establish the values V1 ... Vn as defined
in file H.h:

1)  Attempt the cc -E lookup in H.h.
2)  If any (or all) values remain undefined, try the table lookup
    in /etc/H.
3)  If the user has specified environment variable H-Vi, use that
    instead of any lookup value.
4)  Return the values.

Shuffle the precedence as you see fit.  You can arrange for /etc/H to
override the values in H.h.  You can ignore what's in the environment.
Perhaps we can agree on what makes the most sense, and then somebody
can crank out a routine for public use.

John P. Linderman  allegra!jpl

Volume-Number: Volume 3, Number 35

From jsq  Fri Nov 22 11:31:06 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: duplicate articles
Message-Id: <[e-mail]>
Date: 22 Nov 85 17:30:38 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 5
Approved: [e-mail]
Draft-9: mod.std.unix

The problem of duplicate articles in mod.std.unix seems to be fixed:
it was a new site which got confused during installation.  So unless
you see any duplicates which were *posted* later than today, ignore them.

Volume-Number: Volume 3, Number 36

From jsq  Fri Nov 22 19:57:52 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  limits
Message-Id: <[e-mail]>
Date: 23 Nov 85 01:57:46 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 29
Approved: [e-mail]
Draft-9: 2.9

Date:     Thu, 21 Nov 85 10:43:08 EST
From: Dan Franklin <[e-mail]>

Mark Horton's message on ways of getting kernel-determined limits out
of files implies, to me, that the only reasonable way to get such limits
at runtime is through a kernel system call.  It solves all of the problems
Mark outlined at the cost of a few bytes of data space.

It's not clear that we need to describe the implementation at such a low
level, though.  All we really need is to standardize the interface through
which the information is maintained.  The choice of using a file or a system
call (in fact both might be appropriate, for different limits) is up to the
implementation.

(Mark's message also left me with the uneasy feeling that I might have missed
an issue or two, as I don't remember seeing anything on "cc -E | sed" before.
Have I?)

[ No, you haven't.  We've been having mailer problems associated with flaky
nameservers here and elsewhere, plus BBN sometimes forgets how to talk to us,
and the reverse.  I'll send you the ones you've missed.

Free trial offer, open to anyone:  the Volume-Number line tacked onto the
end is so you can check to see if there are any gaps in what you've received.
Send me a list of ones you didn't get and I'll send them to you again.  -mod ]

    Dan Franklin

Volume-Number: Volume 3, Number 37

From jsq  Fri Nov 22 20:11:32 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  OPEN_MAX and other constants - are they desireable?
Message-Id: <[e-mail]>
Date: 23 Nov 85 02:11:26 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 21
Approved: [e-mail]
Draft-9: 2.9

Date:     Tue, 19 Nov 85 20:57:51 EST
From: Dan Franklin <[e-mail]>

> I have another argument against the desirability of these constants.  It does
> not allow people to do implementations that don't have any limitations (other
> than availability of resources).  It would be fairly easy to design a system
> that would allow you to have an "unlimited" number of files, by allocating
> a new table when the current table gets full.

Even given such a system, I think it would still be desirable to place SOME
limit on the number of open files per process to limit the consequences of
error.  A runaway program could conceivably open an unlimited number of files
and use up the common resources (and also make it difficult to kill the
process).  Limiting a process to 500 or so open files seems like a good idea
(just like most systems put some huge, but definite, limit on the size of a
user's stack).  This arbitrary limit would be the one that the limit facility
would return.

    Dan Franklin

Volume-Number: Volume 3, Number 38

From jsq  Fri Nov 22 20:17:04 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Draft ambiguity
Message-Id: <[e-mail]>
Date: 23 Nov 85 02:16:55 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 25
Approved: [e-mail]
Draft-9: 2.9

Date: Fri, 22 Nov 85 09:34:32 cst
From: ihnp4!uiucdcs!ccvaxa![e-mail] (Scott Preece)

> From: athena![e-mail]
> 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

From jsq  Fri Nov 22 20:29:27 1985
From: Moderator, John Quarterman <[e-mail]>
Subject: ;login article on P1003
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Approved: [e-mail]
Date: 23 Nov 85 02:29:11 GMT
Draft-9: Access.;login:

There's an article in the latest ;login: (USENIX Association Newsletter:
Volume 10, Number 4, October/November 1985) about IEEE P1003.  It's a
condensation of some things you've seen in this newsgroup.  Might be
of interest, might not.

Volume-Number: Volume 3, Number 40

From [e-mail]  Mon Nov 25 17:49:26 1985
From: [e-mail],
        Moderator <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: public domain AT&T getopt source
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 25 Nov 85 23:13:10 GMT
Draft-9: 1003.2.getopt

A couple of days after I posted the getopt source, I finally got
the copy I had ordered from the AT&T toolchest.  They are identical,
except that the one from the toolchest has the following prepended:

1,14d0
< /*
<
<  *      Copyright (c) 1984, 1985 AT&T
<  *      All Rights Reserved
<
<  *      THIS IS UNPUBLISHED PROPRIETARY SOURCE
<  *      CODE OF AT&T.
<  *      The copyright notice above does not
<  *      evidence any actual or intended
<  *      publication of such source code.
<
<  */
< #ident    "@(#)getopt.c    1.9"
< /*    3.0 SID #    1.2    */

AT&T appear to be of two minds about this, since the copy I got
directly by mail from them did not have any such notice, and this is in
fact the same code which *was* published at the Dallas Uniforum, and
made public domain, to boot.  Since the copy I posted was not the
toolchest one, and had no such notice, I guess the notice is irrelevant.

Now to send them a check for $1.80 for the toolchest transmission fee....

Volume-Number: Volume 3, Number 41

From jsq  Tue Nov 26 12:25:18 1985
Path: ut-sally!std-unix
From: [e-mail] (John Quarterman, Moderator)
Newsgroups: mod.std.unix
Subject: Re: Draft ambiguity
Message-Id: <[e-mail]>
Date: 26 Nov 85 18:25:04 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 16
Approved: [e-mail]
Draft-9: 2.9

Date: Mon, 25 Nov 85 11:35:46 pst
From: saber![e-mail] (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

From jsq  Wed Nov 27 16:04:32 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits ltd.
Message-Id: <[e-mail]>
Date: 27 Nov 85 22:04:23 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 25
Approved: [e-mail]
Draft-9: 2.9

From: [e-mail] (Geoff Kuenning)
Date: Tue, 26 Nov 85 21:31:36 pst
Status: O

In article <[e-mail]> allegra!jpl (John P. Linderman) writes:

>3)  If the user has specified environment variable H-Vi, use that
>    instead of any lookup value.

Have you every typed "show *" on VMS (or whatever the syntax is;  I'm
glad to say I've forgotten)?  You will get a list of literally
*hundreds* of environment variables, most of which are absolutely
necessary for the system to work properly.  The result is you can never
find anything.

It is *not* a good idea to cavalierly add variables to the environment.
In the first place, it increases the cost of forking *and* exec-ing,
in the second place every program has to provide for the variable, and
in the third place it makes the user's life more difficult.  I'm already
harassed enough by the size of my environment, thank you.
--

    Geoff Kuenning
    {hplabs,ihnp4}!trwrb!desint!geoff

Volume-Number: Volume 3, Number 43