Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.27

Internet Message Format | 1992-05-20 | 443KB

From [e-mail] Sat Feb 22 01:24:56 1992
Received: from rodan.UU.NET by ftp.UU.NET with SMTP
    (5.61/UUNET-guest-mail-drop) id AA22227; Sat, 22 Feb 92 01:24:54 -0500
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23467; Sat, 22 Feb 92 01:23:28 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09712; Sat, 22 Feb 92 01:23:22 -0500
Newsgroups: comp.std.unix
From: Sean Eric Fagan <[e-mail]>
Subject: Policy and Guidelines for comp.std.unix
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Fri, 21 Feb 1992 22:03:32 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.
Status: R

Submitted-by: [e-mail] (Sean Eric Fagan)

This is a policy statement for comp.std.unix.

This is Volume 27 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Subject: Topic.

The USENET newsgroup comp.std.unix, also known as the mailing list
[e-mail], is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

Other related standards bodies and subjects include but are not limited to
    IEEE 1201 and IEEE 1238,
    ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
    the U.S. and other Technical Advisory Groups (TAGs) to WG15,
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba, GNU,
    and the USENIX Standards Watchdog Committee.

Subject: Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is Sean Eric Fagan.

Subject: Disclaimer.

Postings by any committee member in this newsgroup do not represent
any position (including any draft, proposed or actual, of a standard)
of the committee as a whole or of any subcommittee unless explicitly
stated otherwise in such remarks.  Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.

* UNIX is a Registered Trademark of AT&T.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


Subject: Postings.

Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:

        DNS address            UUCP source route
Submissions    [e-mail]        uunet!std-unix
Comments    [e-mail]    uunet!std-unix-request

In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or cygnus.com (e.g., [e-mail]).  If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.  For submissions, I prefer
[e-mail], as that is where I do the list maintainance.
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.

The mailing list is distributed on the Internet, UUCP, and elsewhere.
There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
Please send submissions from those networks to [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

If you have access to USENET, it is better (more efficient, cheaper,
less effort for me to manage) to subscribe to the newsgroup comp.std.unix
than to the mailing list.  Submissions should still go to the above
addresses, although many (perhaps most) USENET hosts will forward
attempts to post directly to the newsgroup to the moderator.

Posted articles may originate from uunet.uu.net, kithrup.com, or cygnus.com.
There are also occasional guest moderators, who may post from still other
machines.  Guest moderators are announced in advance by the regular moderator.

Subject: Archives.

Archives for comp.std.unix or [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to uunet.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/usenet/comp.std.unix/archive
or
        ~ftp/usenet/comp.std.unix/volume.27
The previous volume may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.26.Z
and so forth for more ancient volumes.

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/usenet/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell.

The output of "cd ~ftp/usenet/comp.std.unix; ls -l" is in
        ~ftp/usenet/comp.std.unix/list
and the output of "cd ~ftp/usenet/comp.std.unix; ls -l *" is in
        ~ftp/usenet/comp.std.unix/longlist

For further details, retrieve the file
        ~ftp/usenet/comp.std.unix/README


Subject: General submission acceptance policy.

Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days.  If you wait
and still don't see anything, try sending again.

As moderator, I reject relatively few artciles:  maybe 1 out of 10;
although that amount varies, it is a good rough estimate.  I retain the
right to reject submissions.  If a submission does not appear relevant
to comp.std.unix, it is sent back to the submittor with a note saying
why it is not appropriate.  Usually this is because it just doesn't fit
the topic of the newsgroup, in which case I suggest another newsgroup.
Sometimes it is because someone else has already given the same answer
to a question, in which case I ask if the submittor really wants it
posted.  Occasionally I suggest editing that would make an article more
appropriate to the newsgroup.  If a message appears to be directed
towards me, I will reply; if I am unsure, I wil ask the sender if
posting is really necessary or desired.

Very occasionally I may reject an article outright:  this will most likely
be because it contains ad hominem attacks, which are never permitted
in this technical newsgroup.  There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.

Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.

Crosspostings are discouraged.  Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix.  This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.



Subject: Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of three types:  headers and trailers; comments; and typographical.

Headers and trailers

Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
    either hosta!hostb!host!user or, preferably, user@domain.
    Very occasionally, this might cause an improper address
    to be generated.  If this occurrs, and you think you may
    submit an article again, send me a note, and I will attempt
    to use an address you suggest next time.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.

The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide.  If it's not of worldwide interest, it doesn't belong in
comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest.  If a submission arrives with a
Distribution:  line, such as na or us, I delete that line.

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.  Due to the way news is transmitted,
articles may appear out of order at some sites if I send out several
at once.

Also, signatures that are excessively long may be truncated.



Subject: Comments

Comments by the moderator are sometimes added to clarify obscure
issues.  These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
appear that are written by the moderator:  these always end with
a signature that includes the words ``moderator, comp.std.unix.''

Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].

Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].

Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.

Subject: Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possesive or
``its'' as a contraction of ``it is'' are corrected (when I notice them).

Excess white space is deleted.  (This includes multiple blank lines at
times.)

Lines longer than 80 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



Subject: Common kinds of postings.

There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals.  Here are three of the most common.

Calendar of UNIX-Related Events

Susanne W. Smith <[e-mail]> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <[e-mail]> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The first three are posted to
    comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.

These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS.  Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is Stephen
E. Walli <[e-mail]>.  Reports on other committees, such as X3J11,
are also included when available.  These reports are published in
comp.std.unix/[e-mail] and ;login:  The Newsletter of the
USENIX Association.  They are also available for publication elsewhere.

EUUG/USENIX ISO Monitor Project

The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee.  This observer, Dominic Dunlop <[e-mail]>,
writes a report after each WG15 meeting, of which there are usually
two a year.  These reports are published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix.  They are also available for
publication elsewhere.

Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on uunet.uu.net.  Retrieve ~ftp/usenet/comp.std.unix/README
for details.

Sean Eric Fagan, moderator, comp.std.unix and [e-mail].

Volume-Number: Volume 27, Number 1

From [e-mail] Sat Feb 22 02:51:06 1992
Received: from rodan.UU.NET by ftp.UU.NET with SMTP
    (5.61/UUNET-guest-mail-drop) id AA23815; Sat, 22 Feb 92 02:51:05 -0500
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25329; Sat, 22 Feb 92 02:50:14 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16421; Sat, 22 Feb 92 02:50:12 -0500
Newsgroups: comp.std.unix
From: Mike Wulkan <[e-mail]>
Subject:       return from a signal-catching function
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Fri, 21 Feb 1992 20:55:50 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.
Status: R

Submitted-by: [e-mail] (Mike Wulkan)

I have a question as to the intent of the following statement in section
3.3.1.3 of 1003.1:

  521 (c) The behavior of a process is undefined after it returns normally
  522     from a signal-catching function for a SIGFPE, SIGILL, or SIGSEGV
  523     signal that was not generated by the kill() function or the raise()
  524     function defined by the C Standard {2}.

whereas the ANSI C Standard states in section 4.7.1.1:

  ...  If func executes a return statement and the value of sig was
  SIGFPE or any other implementation-defined value corresponding to a
  computational exception, the behavior is undefined. ...

Is the intent of Posix to "limit" the scope of "other
implementation-defined value" to exactly SIGFPE, SIGILL and SIGSEGV?

Or is Posix simply extending the list to include SIGILL and SIGSEGV
while still allowing for other implementation-defined values?

Mike Wulkan


Volume-Number: Volume 27, Number 3

From [e-mail] Sat Feb 22 02:51:07 1992
Received: from rodan.UU.NET by ftp.UU.NET with SMTP
    (5.61/UUNET-guest-mail-drop) id AA23817; Sat, 22 Feb 92 02:51:06 -0500
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25315; Sat, 22 Feb 92 02:50:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16389; Sat, 22 Feb 92 02:49:59 -0500
Newsgroups: comp.std.unix
From: Chesley Reyburn <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Computervision R&D, Beaverton OR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 20 Feb 1992 17:47:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.
Status: R

Submitted-by: [e-mail] (Chesley Reyburn)

[e-mail] (Barry Margolin) writes:

>What about the kind of stuff that one needs dlopen() for, i.e. where a
>runtime-specified module must be linked in?  That's a source-level view.

Thank you!  I sent mail yesterday to Mr. Lewine stating the same
thing and proposing something like:

    void *(*local_func())(char *filename, char *entryname)

Where local_func() is part of POSIX.  Filename is a fully qualified
file name where the source code that describes the function may be found.
Entryname describes the entry point in the object.

The only problem that I can see is that the above function
limits the new functions to always only returning a pointer
to void.  Perhaps an additional argument describing the type
of return value?

Chesley Reyburn                       [e-mail]
ECAE Software, Prime Computer, Inc.   Phone: [phone]
14952 NW Greenbrier Parkway           Beaverton, OR 97006-5733, USA


Volume-Number: Volume 27, Number 2

From [e-mail]  Sat Feb 22 18:44:14 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25673; Sat, 22 Feb 92 18:44:14 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25730; Sat, 22 Feb 92 18:44:12 -0500
Newsgroups: comp.std.unix
From: Barry Margolin <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 22 Feb 1992 16:21:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (Chesley Reyburn) writes:
>Thank you!  I sent mail yesterday to Mr. Lewine stating the same
>thing and proposing something like:
>
>    void *(*local_func())(char *filename, char *entryname)
...
>The only problem that I can see is that the above function
>limits the new functions to always only returning a pointer
>to void.

I don't think that's a problem.  The caller should be required to cast the
returned pointer to the actual type of the function that is being linked
in.  So, if you're trying to dynamically load a function that returns an
int, you would write:

int (*foo_fun)();
foo_fun = (int (*)()) local_func(filename, entryname);

BTW, why did you specify void* in the first place?  Since the default
return type in C is int, it would probably be more intuitive for
local_func() to return an int function rather than a void* function.
Another reasonable default would be a void function.  But either way, the
caller will have to cast it if the default isn't appropriate for that
function.

--
Barry Margolin
System Manager, Thinking Machines Corp.

[e-mail]          {uunet,harvard}!think!barmar


Volume-Number: Volume 27, Number 4

From [e-mail]  Sat Feb 22 18:44:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25688; Sat, 22 Feb 92 18:44:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25740; Sat, 22 Feb 92 18:44:16 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]>
Date: Sat, 22 Feb 1992 17:28:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Mike Wulkan) writes:
>Submitted-by: [e-mail] (Mike Wulkan)
>I have a question as to the intent of the following statement in section
>3.3.1.3 of 1003.1:
>
>  521 (c) The behavior of a process is undefined after it returns normally
>  522     from a signal-catching function for a SIGFPE, SIGILL, or SIGSEGV
>  523     signal that was not generated by the kill() function or the raise()
>  524     function defined by the C Standard {2}.
>
>Is the intent of Posix to "limit" the scope of "other
>implementation-defined value" to exactly SIGFPE, SIGILL and SIGSEGV?
>
>Or is Posix simply extending the list to include SIGILL and SIGSEGV
>while still allowing for other implementation-defined values?

SIGFPE, SIGILL, and SIGSEGV are the signal names defined by
POSIX.1 that correspond to computational exceptions.  Elsewhere
in POSIX.1 it is stated that the implemention may generate
other, implementation-defined signals.  The names of these
signals and the conditions under which they are generated
are to be documented in the POSIX conformance document.

POSIX.1 tries not to keep the implementation from providing
additional signals or errno values that give more information
to the programmer, as long as the base behavior specified
by the Standard is also supported and the appropriate
documentation is provided.


    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 27, Number 5

From [e-mail]  Sat Feb 22 18:44:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25697; Sat, 22 Feb 92 18:44:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25754; Sat, 22 Feb 92 18:44:23 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 22 Feb 1992 17:48:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Chesley Reyburn) writes:
>Submitted-by: [e-mail] (Chesley Reyburn)
>[e-mail] (Barry Margolin) writes:
>>What about the kind of stuff that one needs dlopen() for, i.e. where a
>>runtime-specified module must be linked in?  That's a source-level view.

The charge of the POSIX.1 committee was to codify existing
practice in the industry.  I think the examples of prior art used
to represent existing practice were 4.2BSD and System 5 Release 1.
Neither of these supported dynamic linking.

>Thank you!  I sent mail yesterday to Mr. Lewine stating the same
>thing and proposing something like:
>
>    void *(*local_func())(char *filename, char *entryname)
>
>Where local_func() is part of POSIX.  Filename is a fully qualified
>file name where the source code that describes the function may be found.
>Entryname describes the entry point in the object.

The problem, of course, is that local_func() is not part
of POSIX.1.  If the POSIX.1 work were starting today,
dynamic linking would probably be a part of the committee's
work and would probably be the subject of a battle over
what model to adopt.

As Don Lewine pointed out, POSIX.1 does not contain any
concept of compiling or linking.  That's handled, for now,
in an optional section of POSIX.2.  The right place for
dynamic linking in the POSIX scheme would be in POSIX.1, but
it would require a change in that standard's scope as
well as consideration of the constraints this would
impose on other standards.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 27, Number 5

From [e-mail]  Sun Feb 23 17:58:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21356; Sun, 23 Feb 92 17:58:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05442; Sun, 23 Feb 92 17:57:51 -0500
Newsgroups: comp.std.unix
From: Chesley Reyburn <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Computervision R&D, Beaverton OR
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 23 Feb 1992 19:57:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chesley Reyburn)

[e-mail] (Chuck Karish) writes:

>As Don Lewine pointed out, POSIX.1 does not contain any
>concept of compiling or linking.  That's handled, for now,
>in an optional section of POSIX.2.  The right place for
>dynamic linking in the POSIX scheme would be in POSIX.1, but
>it would require a change in that standard's scope as
>well as consideration of the constraints this would
>impose on other standards.

I am really confused by a scope that allows things such as
fork() and longjmp() and not dynamic linking.  I actually
don't care how POSIX makes the source code specified in
local_func() available to me.  It can use mutated cockroaches
instead of compilers for all I care. :->  I just want functional
access to source code specified during execution.

I realize that the books are written and the standards published.
But standards are revised from time to time.  Especially if they
are used a lot.  I expect POSIX to get used a LOT.  What I would
like is an agreement in principle that the next time POSIX.1 gets
revisited, dynamic linking gets included.

Chesley Reyburn                       [e-mail]
ECAE Software, Prime Computer, Inc.   Phone: [phone]
14952 NW Greenbrier Parkway           Beaverton, OR 97006-5733, USA


Volume-Number: Volume 27, Number 6

From [e-mail]  Mon Feb 24 18:11:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07269; Mon, 24 Feb 92 18:11:50 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16962; Mon, 24 Feb 92 18:11:28 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update - Editorial
Message-Id: <[e-mail]>
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:51:13 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

ENOBANDWDTH
Stephe Walli
USENIX Standards Report Editor

[ENOBANDWDTH] - No Band Width Left An asynchronous signal was caught
(such as SIGBALLOT, SIGPLSCOMMENT or SIGMORE2RD; See the description of
<signal.h> in 3.3.1) while the programmer process was busy dealing
with the last such signal.  The current handler shall be interrupted
after attempting to save context, and the new handler begins to
execute.  Signals shall continue to be delivered, interrupting one
another, until {_POSIX_LAST_STRAW} is reached.  (See description of
Run- Time Randomly Varying Values in 2.8.4.1; Please note sysconf()
always returns either a value of one greater than the true value at
any particular time, or the return value from rand().) Once the true
value of {_POSIX_LAST_STRAW} is reached, the entire precarious stack
comes clattering down.  The last interrupt handler with enough context
to still maintain some semblance of integrity returns [ENOBANDWDTH].
A programmer process may attempt to notify its parent process of the
condition in an implementation defined way, but it shall be ignored.

All joking aside, POSIX is finally beginning to strain the seams of
the working groups, along with the standards process in which it lives.

There was a time when POSIX meant a working group of around 20 people
defining a system interface for source code portability, based on the
C language interface to UNIX (356 pages). Then it started to grow.

The shell and utilities were added (~ 900 + ~ 300 pages) making
POSIX.2.  Someone thought conformance testing should be done in a
standard way, and since they started suspecting POSIX was going to
grow some more, they decided to make a standard for defining test
methods (47 pages).  Then there were the test methods themselves.
(Another 500 pages each for POSIX.1 and POSIX.2 so far.) Then came
real-time, to take all the real-time sorts of things that POSIX.1
couldn't settle on, along with a few things of interest only to the
real-time community. (Another ~ 400 pages, plus threads.)

You can continue in this vein for quite some time. The POSIX.20 (Ada
Bindings for POSIX.4/.4a Real-time services) project has recently
started up.  This doesn't take into account the other related IEEE
Technical Committee on Operating Systems standards (P1201 GUIs, P1224
X.400, P1238 FTAM).

The working groups NOW number between 350 and 400 people, who attend
four one week long meetings a year. (As an aside, do the back of the
envelope calculation as to the amount of money that represents. Using
350, $2000/week expenses, and a loaded staff cost of another
$1500/week, I get $4,900,000/year.) The working groups generate a
considerable quantity of reading material, documenting discussions and
decisions, reviewing and co-ordinating with related efforts, proposing
alternatives, and commenting on other proposals.  This all on the way
to producing the actual draft document to ballot as a standard.

An average C programmer or applications designer would likely be
interested in the base interfaces (POSIX.1), most of the real-time
services (POSIX.4), some security (POSIX.6), and possible some of the
networking (Transparent File Access - POSIX.8, and Protocol Independent
Communications - POSIX.12). And of course the shell (POSIX.2/.2a).
Whew! That's a lot of paper.  POSIX Zen koan:  Does a tree scream in
the wilderness every time a new project request is approved?

Before all the Ada and Fortran programmers start howling about the
``C'' programmer reference, let me explain. Until recently, the Ada or
Fortran involvement in POSIX has been two small working groups who
realised very early in the game that this standard was going to be
extremely important. They have each now produced a standard binding of
their respective languages to the C-based POSIX.1 standard.

The Ada working group is now beginning to address POSIX.4 and
POSIX.4a.  The Fortran working group is beginning a Fortran 90 version
of POSIX.1 (the original POSIX.9 standard being an F77 binding.) These
groups are well placed to begin opening the way for a large segment of
the systems building community that doesn't work in C to gain access
to the benefits of a standard systems interface. They are, however,
the exceptions to date, rather than the rule.

With several vendors delivering POSIX.1 interfaces and POSIX.2 shells
on their non-UNIX derived operating systems, the growth of interest in
POSIX based open systems is only just beginning.  This could bring in
a badly needed injection of new blood to the POSIX working groups.  BUT
these people will not have the often needed historical context.  They
will require some time in the system to come up to speed on all of its
perversities.

Let's argue that you do care about all of these related base
standards.  (You should! They are being forced upon you in many
cases.) That means you should be involved enough to at least ballot.
Maybe not every section of every document, but certainly sections in
each of these drafts. You cannot standby idly trusting that a good
standard will fall out of the end of the process, and you can then use
it. If you are a member of a technical user group such as USENIX, then
the only difference between you and the people building the POSIX
standards are that they've found the financial support of their
organisations to attend the meetings. Think about it.

If you cannot attend the meetings, then you should ballot the draft
documents.  (Ballot early! Ballot often!) But this then brings us back
to [ENOBANDWDTH].  The balloting schedule for 1992 (as taken from a
balloting status report of last December) looks something like the
table.

          Project               Ballot       Date        Size
_______________________________________________________________
POSIX.0 (Guide)               1st Ballot   July 92     ~250 pgs
POSIX.1a (More .1)            1st Ballot   Summer 92   ~100 pgs
POSIX.1/LIS                   1st Ballot   Spring 92   ~400 pgs
POSIX.2a (UPE)                3rd Recirc   Jan 92      ~300 pgs
POSIX.3.2 (.2 Test methods)   1st Ballot   Spring 92   ~500 pgs
POSIX.4 (Real-time)           3rd Recirc   Spring 92   ~320 pgs
POSIX.4a (Threads)            1st Recirc   Winter 92   ~200 pgs
POSIX.4b (More Real-Time)     1st Ballot   Fall 92     tbd
POSIX.5 (Ada)                 Final        Spring 92   ~300 pgs
POSIX.10 (Super. AEP)         1st Ballot   July 92     ~75 pgs
POSIX.12 (Protocol Indep.)    1st Ballot   Fall 92     ~400 pgs
POSIX.13 (Real-time AEP)      1st Ballot   Spring 92   ~80 pgs
POSIX.15 (Batch)              1st Ballot   July 92     ~175 pgs
POSIX.16 (C Binding)          1st Ballot   Spring 92   ~200 pgs
POSIX.17 (Direct. Serv.)      1st Ballot   Spring 92   tbd
POSIX.18 (PEP)                1st Ballot   Spring 92   tbd

A few of these are a little bit specialized, such as POSIX.10
(Supercomputing Profile), POSIX.13 (Real-time Profiles), POSIX.15
(Supercomputing Batch Interfaces), and POSIX.17 (Directory Services).
Note, however that these are the smaller documents.  And I haven't
mentioned the non- POSIX TCOS standards from P1201 (GUI), P1224
(X.400), and P1238 (FTAM) that are also sending drafts to ballot in
1992.

After a punishing year of balloting in 1991, the Ballotting Vice-Chair
is staging the drafts so as to not completely bury the balloting
groups in which there is often a lot of overlap. This means a working
group had better hit its target date, or it will be left stuck
circling the balloting schedule, looking for another time slot to hit.

This heavy balloting load is starting to lead to the break down of the
mock balloting process. In the ``good ol' days'' a document could be
sent to mock ballot to test the waters, before committing to the
serious work of a formal ballot.  With so many documents out for
formal ballot, most mock ballots are finding themselves at the bottom
of the pile.  [ENOBANDWDTH]

The heavy balloting of large documents to large balloting groups is
beginning to take its toll in other ways. The IEEE Standards Office
can no longer absorb the entire cost of copying and distribution. For
the first time in POSIX's history, the current invitation to ballot is
charging a fee per document ($25) to join the group.  [ENOFINANCES]?

We've really only touched on the balloting load. If you are serious,
and you find the financing, you can look forward to spending four
weeks a year in exotic locations like Parsippany, New Jersey, at the
working group meetings. If you stick strictly to a working group or
two, you will actually be able to get out of the hotel for dinner.
(Parsippany didn't have a lot to offer here, but then we have been to
New Orleans.)

If you are interested in any of the cross group issues, such as
Language Independent Specifications, Conformance Testing, or most
important of all, the overall structure of the POSIX standards, and
the process of building it, you can look forward to six 12 to 13 hour
days (not five).

If you are a serious participant, i.e. you actually do work between
meetings, you probably spend at least another week of your time on
POSIX for every week of meeting time.  Unless you are self-employed,
it is unlikely you do this in plain sight at your place of business.
It's generally frowned upon. After all, your manager already feels he's
paying for you to attend four of these ``conferences'' a year.
[ENOSUPPRT]?

It is often surprising to discover how little corporate support exists
for people in the process. There are many stories of people who cannot
find the consistent support to participate, either moral or financial,
who work for companies you would assume have an obvious stake in POSIX.
While their companies love to bask in the glow of their ``obvious
commitment to open systems'', their people are put through the wringer
trying to get the job done right.  (Please see the last line of the
ENOBANDWDTH definition again.)

So the coming year will be interesting. As many of the POSIX projects
reach ballot, the number of documents circulating in ballot grows. The
relentless and blind pressure from the market place to build more
standards faster, will grow, rather than fade. The number of POSIX
projects will continue to grow, before we've even figured out how the
current ones integrate. Hark - I hear a tree screaming.






















































Volume-Number: Volume 27, Number 7

From [e-mail]  Mon Feb 24 18:12:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07271; Mon, 24 Feb 92 18:12:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16943; Mon, 24 Feb 92 18:11:23 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.4, POSIX.4a, POSIX.13, POSIX.4b Real-time Extensions
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:52:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen Walli <[e-mail]>, Report Editor
Report on POSIX.4, POSIX.4a, POSIX.13, POSIX.4b Real-time Extensions


Bill O. Gallmeister <[e-mail]> reports on the January 13-17
meeting in Irvine, CA:

Summary

This meeting, we concentrated on the real-time profiles document
(POSIX.13), and on the new real-time interfaces (POSIX.4b).  POSIX.13
was released to ballot at the end of this meeting.  In addition,
technical reviewers for POSIX.4 and POSIX.4a were able to make good
progress on their respective drafts.  POSIX.4 may complete balloting
in the Fall of 1992; POSIX.4a will probably take another six months
after that.  Our current intention is to ballot POSIX.4b after the
October meeting.  By that time, POSIX.4 itself should be through the
IEEE balloting process and into an ISO ballot, though we will probably
still be balloting POSIX.4a.

POSIX.13:  Real-Time Profiles

The big news here is that POSIX.13 is now ready to ballot!  After a
number of small mock ballots, the working group closed on what should
be the functionality in each of the four profiles contained in
POSIX.13.  POSIX.13 is the first POSIX profile document to reach
ballot. With any luck, we will begin POSIX.13 ballot resolution at the
April, 1992 meeting.

POSIX.4b:  New Real-Time Interfaces

Our goal this week was to settle on the contents of POSIX.4b and to
produce first drafts of each chapter. We came close.  Some first
chapter drafts should be coming in the mailings.

POSIX.4b includes chapters for: interrupt control; timeouts on all
blocking functions; enhanced memory allocation; sporadic server
scheduling; spawn (a combined fork/exec); the ability to wait on
multiple things, also known as event flags; CPU time budgeting (the
ability to set time budgets for other processes/threads and examine
time spent by those processes/threads); and more interfaces for
driver/application communication (i.e., ioctl).  Some of these
chapters actually did make it into the draft by Friday.  Other
facilities were brand new, and are still being debated (CPU time
budgeting, event flags and ioctl were especially contentious).  The
contents are not cast in stone, but it indicates the small groups
which the working group will form at the next meeting.

Ioctl

The standard method of driver/application communication, aside from
the obvious read/write, is ioctl.  POSIX.1 elected not to standardize
ioctl, instead preferring to provide alternate standard interfaces to
control those devices, such as TTYs, for which a standard set of ioctls
existed.  For devices which were not standard, POSIX.1 did not wish to
provide a standard interface for doing non- standard things.

There was some agreement with this approach in POSIX.4, but the idea
had been raised that perhaps there were a suitable set of standard
devices which might benefit from standard ioctls (SCSI devices, IEEE
488 devices, and so forth).

A small group (me) gathered up a list of standard devices for
consideration for a standardized control interface.  Whether the
interface was ioctl or not is, at this point, largely immaterial.
When this list was presented, it was rather short; it turned out that
most of the impetus for ioctl is not the desire to perform standard
I/O operations (rewind a tape, eject a floppy), but rather to do non-
standard things (rotate a radar, drop some control rods, e.g.).  We
decided to form a small group to further explore this issue.

Enhanced Memory Allocation

An interface by which memory can be allocated from various special
pools (NVRAM, Video Ram, for instance) is standard practice in much of
the real-time community.  This is the idea behind an enhanced memory
allocation interface. It was pointed out that the mmap() facility
could be used to carve off parts of an appropriate memory area, and an
allocator could be easily constructed at application level based on
this.  This was seen to be the correct way of allocating special
memory.

Asynchronous Interfaces

Some have requested that POSIX.4 provide asynchronous interfaces to
blocking services. Some objected that we have already done so;
POSIX.4a provides an asynchronous interface to any system interface by
allowing threads to be created for the purpose of using those
interfaces without suspending the original thread.  For instance, an
asynchronous open routine can easily be emulated by creating a
separate thread to perform a synchronous open, then signal the
original thread and go away.  Despite this, we have an agenda bullet
to explore this possibility in Dallas this April.

POSIX.4 and POSIX.4a Draft Status

POSIX.4 has completed its third round of balloting and the ballot
objections are dropping off in a gratifying fashion.  The draft should
be out for its next-to-last recirculation by the April meeting.  IEEE
approval is expected in the Fall of 1992. POSIX.4a is approaching its
next circulation and should be re-circulated by the Fall meeting as
well.  POSIX.4a will actually be re-balloted rather than re-
circulated, because it was not able to achieve a 75% approval rate.
This means that the entire draft will be open for comment, rather than
just the parts of the draft that have changed from the previous
draft.  The balloting group, however, will remain the same.


Volume-Number: Volume 27, Number 8

From [e-mail]  Mon Feb 24 18:12:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07273; Mon, 24 Feb 92 18:12:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16988; Mon, 24 Feb 92 18:11:32 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.5, POSIX.20: Ada Bindings
Message-Id: <[e-mail]>
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:54:21 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee

Stephen Walli <[e-mail]>, Report Editor
Report on POSIX.5, POSIX.20: Ada Bindings


Del Swanson <[e-mail]> reports on the January
13-17 meeting in Irvine, CA:

The POSIX.5 working group is producing an Ada binding to the C-based
POSIX.1 document. The group is also involved with a new project,
POSIX.20.  This will be an Ada binding to the programming language
independent specification of POSIX.4 (Real-time Extensions) and
POSIX.4a (Threads).

The meeting in Irvine was spent on the finishing touches to the
POSIX.5 document, which is finishing ballot, and getting a good start
on the new POSIX.20 work.

The group had been somewhat shocked at the overwhelming positive
response to the first recirculation of the POSIX.5 document. There was
almost 90% approval by the almost 300 balloters. This is a compliment
to the great ballot resolution job on the part of the technical
reviewers. It was a slight embarrassment, however, since there were
known errors in the draft. In fact, the draft had been sent out for
recirculation even though an error had been discovered at the last
minute. We assumed that it could be fixed in the next recirculation.

The group decided to ``do the right thing'', and make one more
recirculation with minor editorial changes and a couple of error
corrections. Draft 8 is expected to be the final recirculation. It
should have a fast turn-around, and it is expected to be approved at
the June meeting of the IEEE Standards Board.

Several new members have joined the group because of their interest in
the POSIX.20 binding of the real-time extensions.  They showed
themselves to be eager participants, astute observers, and acquainted
with the issues we will be facing in this task.

The single issue that will demand our attention more than any other
during the binding deliberations is how the relationship of Ada tasks
to POSIX.4a threads will be represented in the binding. As background,
most of us are convinced that the p-threads as defined in POSIX.4a will
provide an adequate capability for Ada implementations to use for a
direct mapping of Ada tasks. Further, we believe that the services
provided in the POSIX.4 materials will be sufficient for a reasonably
straight-forward implementation of Ada tasking semantics by Ada
runtime libraries.

Nevertheless, the semantics of tasks are not identical to the
semantics of threads (for example, Ada allows no orphans). Further,
since Ada as a language introduces concurrency along with the rules of
interactions, the runtime libraries of Ada implementations like to be
able to make assumptions about the state of tasks. Disrupting this
state would likely be disastrous.  For example, if an application
directly aborted a thread (which had been mapped as a task) the
runtime library could become quickly confused.

Opinions about how to deal with this situation range widely, and tend
to be held strongly. Some participants believe that services such as
pthread_create() that are available via language construct (declare a
task) should not be visible to applications by direct call to the
operating system. Others believe that every interface should be made
directly visible by way of the Ada binding. Many attempts are being
made to integrate the needs of the various factions. This issue will
arise in many ways throughout the entire POSIX.20 project.

One issue that was resolved was the basic character of the binding.
The IEEE POSIX working groups have taken the lead from ISO WG15 (ISO
POSIX) that all POSIX standards will be formulated as language
independent specifications (LIS), and this will be accompanied by a
series of thin programming language bindings.  While there continues
to be scepticism evidenced by some members of the group, who doubt the
wisdom (or the possibility) of this approach, we agreed that we would
be converts to the cause.

We will produce a thin binding to the LIS versions of POSIX.4 and
POSIX.4a.  We will do so enthusiastically. We will help the POSIX.4
working group in so far as we can to produce a viable LIS version.

We are fortunate that a couple of our members have received funding to
give us a head start on some labor-intensive activities. The U.S. Navy
funded a solid first draft of the test assertions for POSIX.5. The
U.S. Army funded a first draft thin Ada binding (or transliteration)
of the existing C-based POSIX.4 document.

In summary, we are expecting some significant progress at our next
meeting, now that most people are oriented to the issues.  Several
people have volunteered to write position papers, and to start working
on chapters to present for consideration in April.

Your Ada Snitch.


Volume-Number: Volume 27, Number 9

From [e-mail]  Mon Feb 24 18:12:43 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07364; Mon, 24 Feb 92 18:12:43 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17125; Mon, 24 Feb 92 18:11:53 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, U.S. Standards Technical Advisory Groups
Message-Id: <[e-mail]>
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:56:36 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

John Hill <[e-mail]> reports on U.S. Standards Technical
Advisory Groups


Standards, like automobiles, come in several sizes, shapes, and colors
suitable to the use to which they will be put.  With cars there are
options for just about everything; from appearance, to utility, to
emissions control.  Not only that, cars are also sold with features
specifically accommodating the place in which they are to be used.  If
you don't have a strong grasp of what that means then try driving your
'61 Ford Fairlane down any London street during crush hour.  Your car
won't fit, it's too wide.  Its outside mirrors aren't a breakaway
type, so you are dangerous to pedestrians.  Not to mention that you
steer on the wrong side of the car for the side of the street on which
you are driving. In London cars have features to accommodate their
situation.  Just like your '61 Fairlane fits local US requirements in
the early sixties.

What does this have to do with standards?  A lot.  The analogy helps
highlight some of the problems of developing worldwide standards.
Driving and cars provide interesting examples.  It would be helpful if
it were simpler to drive in foreign places without being a hazard to
the local inhabitants, as well as to one's self.  What's more, it
would be convenient to have the same situation, in terms of driving
conditions and cars, presented all over the world.  But, in the UK
there are unique local requirements for cars, just as there are in all
other nations of the world.

Consider the situation.  In countries the world over, the local people
know their driving conditions better than anyone and from them can
determine the requirements for a suitable car.  After all, they face
the situation every day.  But conditions differ from country to
country.  This places different requirements on the cars to be
operated in each country.  From a producer perspective, this results in
different product variants to accommodate each country in which the
product is used.  From a world user perspective, this results in
inconvenience during use.  (It does however, simplify the matter of
determining where you are.  All you have to do is look at the car
you're driving.)  From a general interest perspective, it is confusing
at best and baffling at its worst.

Information technology exhibits many of the same properties as cars.
In the case of telecommunications, there truly are a multitude of
factors which take on local values.  One trivial example is the
assignment of characters to numbers on the telephone keypad.  A
tougher problem is the variability in the quality of phone line
service across the broad spectrum of transmission rates.  Please
recognize that these examples are objective, deterministic and based on
universally accepted physical laws and phenomena.  Software is, well,
softer.  In any event, there is great interest in having a single
worldwide standard wherever feasible.

Standards bodies

Enter IEC, CCITT and ISO.  These are the organizations which develop
formal worldwide standards.  Their names are actually French and won't
be cited here.  It is useful to recognize that, as a general
characterization of their scopes, they handle electrotechnical (e.g.
safety, EMI), telecommunications (e.g.  ISDN) and everything else (e.g.
food storage, mechanical contraceptive devices, fuels and lubricants)
respectively.  Development of standards for information technology
spans the traditional boundaries of both ISO and IEC and, as such, is
managed jointly by both ISO and IEC in Joint Technical Committee 1
(JTC1).

The membership of ISO, IEC, CCITT and JTC1 is at a higher level than
organizations.  CCITT is a treaty organization; the U.S. is
represented by the Department of State.  ANSI represents the U.S.  as
the member body in ISO, the national committee in IEC, and the
national body in JTC1.  AFNOR, BSI, SIS, DIN and ON, as examples, are
the national body representatives of France, the UK, Sweden, Germany
and Austria respectively.  Other standards bodies participate in a
limited manner.  The most visible of these is the regional standards
developer, the European Computer Manufacturers' Association (ECMA).

If one were to examine the scope of technical activity of JTC1, the
unavoidable conclusion is that it's broad and deep.  Not only does it
cover a lot of ground (media to programming languages) but also in
excruciating detail.  It is unrealistic to expect that a single
organization can develop and promote a national body position in all
the JTC1 technical activities.  In the U.S., the concept of Technical
Advisory Group (TAG) was put forward to handle this.

Tags

TAGs are enabled by ANSI to develop the U.S. position on a limited set
of items for specifically identified JTC1 activities.  What's that
mean?  Essentially, that ANSI assigns to individual standards bodies
the responsibility of handling U.S. technical interest for specific
international standards activities.

Most of the time the enabling of specific organizations to act as a
TAG for an international standards development effort is simple and
not controversial.  Individual programming languages, developed in
working groups of JTC1 subcommittees, are typically simple.  For
example, there is only one U.S. group developing standards for POSIX,
IEEE's P1003, and one for COBOL, X3's technical committee, X3J4.  As a
result, the identification of the TAG for those working groups is
straight forward.

Sometimes the assignment of TAG responsibility is not so easy.  Take
the example of JTC1's subcommittee on languages, SC22.  There are
several U.S. standards development organizations which make-up the TAG
to SC22. The IEEE has POSIX and Modula-2; CODASYL has FIMS; the
Department of Defense has Ada; and X3 has a multitude of others.
Within X3, a subgroup manages the issues that overlap those TAGs or
that do not fall within the activities of any of them.

As a sidelight allow me to point out that the U.S. even needs a TAG to
JTC1 itself.

Let's regroup for a moment.  There are TAGs in the U.S. for all levels
of ISO, IEC, CCITT and JTC1 in which the U.S. has an interest.  Using
JTC1 as a representative example, this means there are TAGs with
responsibility for JTC1 itself, for the JTC1 subcommittees, for the
JTC1 special working groups, for the JTC1 technical subcommittees, and
for the working groups of each JTC1 technical subcommittee in which
the U.S. is interested.  If there is activity anywhere within JTC1
that is of interest to the U.S., there is a TAG.  Someone has to do
the work.

Work of TAGS

A logical question now is "What are these TAGs empowered to do?"
Simple question, but a complex answer.  There are, however some rules
of thumb to help out.

   - the more important the decision, the higher the U.S.  consensus
     that is required

   - the more detailed and technical the subject, the higher the
     weight given to the opinions of technical experts

Some examples are useful.  One action JTC1 places a heavy value on is
the final approval of standards.  As a result, JTC1 rules require that
a ballot be taken of its members (remember them, they're the
representative national standards organizations) for adopting a
document as a worldwide standard.  Similarly, JTC1 members must vote to
approve new work items.  One way to think of this is that JTC1 makes
decisions that affect the beginning (i.e.  approval of new work items)
and ending (i.e. final approval) for standards.  JTC1 also makes all
decisions involving the establishment and dissolution of its immediate
subgroups.

JTC1 TAG establishes the U.S. positions on matters such as new work
items and final approval of standards.

Let us examine a lower level, technical decision of JTC1.  If we apply
the second rule from above, we will conclude that the decisions at
this level are delegated to the working group (of the technical
subcommittee of JTC1).  One such decision is the determination of what
text should be contained in a draft standard.  It doesn't get much more
detailed or technical than that.  The working group determines that.
All by themselves.

There is a whole world of grey between the two examples cited above.
Typically the decisions revolve around ``recommendations to forward''
documents in various stages of completion for consideration or
approval by higher authority committees.  A complete description of the
decisions and recommendations is not really appropriate for this
article.  However, if you're interested allow me to point you to two
companion documents.

   - the JTC1 directives (available from ANSI)

   - the JTC1 TAG technical document 1 (available from CBEMA)

They are in the form of procedures but for ease of use have
comprehensive indices.

There are a few messages for you to carry away.

   - TAGs are empowered by ANSI

   - TAGs represent the U.S.

   - there are TAGs for every worldwide standards activity that is of
     interest to the U.S.

   - the more important the decision, the higher the need for national
     body consensus; the more technical the decision, the lower the
     need for national body consensus

This has been a brief exposure of technical advisory groups in the
U.S..  As you have observed, the subject is complicated.  The best way
to understand them is to join one that is in your particular area of
interest and expertise.  Rather than fuss and fret about the problems
you see with them, it is recommended that you become a part of the
solution.


Volume-Number: Volume 27, Number 11

From [e-mail]  Wed Feb 26 15:30:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16267; Wed, 26 Feb 92 15:30:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29715; Wed, 26 Feb 92 15:30:08 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: X/Open's XTI standard & OSF's TLI standard
Message-Id: <[e-mail]>
Keywords: XTI, TLI, API
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Hughes Aircraft Company
Date: Tue, 25 Feb 1992 18:51:06 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

Does anyone out there have any information regarding
X/Open's XTI (X/Open Transport Interface) API standard
or OSF's TLI (Transport Layer Interface) API?

We are presently looking into incorporating one of the
above API standards into our applications, and therefore
need more information about them.   I'm interested
finding out what the status of these standards is, how
to obtain a copy of the standard, and if any
implementations exist.

I'll post a summary of the volume of responses warrant it.

thanks in advance.

-----------------------------------------------------------
Scott Thomas                      |
Space & Communications Group      | ...still searching for
Hughes Aircraft Co.               | the perfect sigature...
[e-mail]  |


Volume-Number: Volume 27, Number 14

From [e-mail]  Wed Feb 26 15:31:13 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16301; Wed, 26 Feb 92 15:31:13 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29720; Wed, 26 Feb 92 15:30:09 -0500
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 25 Feb 1992 21:51:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

Peter Collinson noted in the recent Standards Update that there was
opposition to a standard non-blocking system call interface, on the
grounds that the threads interface provided the same functionality.

For the case where threads are implemented in user mode, or as a side
effect of threads, it's likely that most implementations will have
some such facility anyway. Given this, I think it would be highly
desirable to spell out a standard interface, whether or not the facility
itself is mandated.

In the past I have seen two families of interfaces to this, either one
of which would be acceptable: In the first, you allocate some sort of
magic token (LUNs, Event Flags, Signal Bits, etc...) from a pool, and
pass them to the asynchronous call interface. You can later test or wait
on these tokens to see if an event has occurred. The other interface is
for the async call to return a token which you can use later, similar to
the way UNIX file handles work.

Personally, I prefer the latter interface. It's similar to the existing
UNIX open/read/write setup, and the tokens could even be file descriptors
in some implementations.



Volume-Number: Volume 27, Number 13

From [e-mail]  Wed Feb 26 15:31:14 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16304; Wed, 26 Feb 92 15:31:14 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29774; Wed, 26 Feb 92 15:30:19 -0500
Newsgroups: comp.std.unix
From: "Mike Wulkan" <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>,
Date: Wed, 26 Feb 1992 13:08:42 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Mike Wulkan")

In article <[e-mail]>,
[e-mail] (Chuck Karish) writes:

>SIGFPE, SIGILL, and SIGSEGV are the signal names defined by
>POSIX.1 that correspond to computational exceptions.  Elsewhere
>in POSIX.1 it is stated that the implementation may generate
>other, implementation-defined signals.  The names of these
>signals and the conditions under which they are generated
>are to be documented in the POSIX conformance document.
>
>POSIX.1 tries not to keep the implementation from providing
>additional signals or errno values that give more information
>to the programmer, as long as the base behavior specified
>by the Standard is also supported and the appropriate
>documentation is provided.

I had no question regarding additional implementation defined signals.
My question was whether an implementation could choose to designate one
of the other Posix defined signals as "computational" with regards to
the undefined behaviour when returning from a handler?  I think the
answer is no.

On a similar note, there seems to be a contradiction in the
section describing SIG_IGN which reads:

  "Delivery of the signal shall have no effect on the process.
  The behavior of a process is undefined after it ignores a SIGFPE,
  SIGILL, or SIGSEGV signal ..."

Why would the behavior of a process be UNDEFINED if the signal has NO
EFFECT on the process?  Obviously the signal has an effect!  Why not
simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
is done for SIGKILL and SIGSTOP?  At the very least it would seem that
the section would be more accurately worded:

  The behavior of the process is undefined after a SIGFPE, SIGILL, or
  SIGSEGV signal is delivered, otherwise delivery of the signal shall
  have no effect on the process.

Mike Wulkan


Volume-Number: Volume 27, Number 15

From [e-mail]  Wed Feb 26 15:39:48 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17304; Wed, 26 Feb 92 15:39:48 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02493; Wed, 26 Feb 92 15:39:46 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Mon, 24 Feb 1992 22:49:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Mike Wulkan) writes:
>Is the intent of Posix to "limit" the scope of "other
>implementation-defined value" to exactly SIGFPE, SIGILL and SIGSEGV?
>Or is Posix simply extending the list to include SIGILL and SIGSEGV
>while still allowing for other implementation-defined values?

The latter.


Volume-Number: Volume 27, Number 12

From [e-mail]  Wed Feb 26 18:03:11 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00795; Wed, 26 Feb 92 18:03:11 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15192; Wed, 26 Feb 92 18:03:07 -0500
Newsgroups: comp.std.unix
From: Michael I Bushnell <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Free Software Foundation, Cambridge, MA
References: <[e-mail]>, <[e-mail]>
Date: Wed, 26 Feb 1992 22:02:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] ("Mike Wulkan") writes:

   On a similar note, there seems to be a contradiction in the
   section describing SIG_IGN which reads:

     "Delivery of the signal shall have no effect on the process.
     The behavior of a process is undefined after it ignores a SIGFPE,
     SIGILL, or SIGSEGV signal ..."

   Why would the behavior of a process be UNDEFINED if the signal has NO
   EFFECT on the process?  Obviously the signal has an effect!  Why not
   simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
   is done for SIGKILL and SIGSTOP?  At the very least it would seem that
   the section would be more accurately worded:

     The behavior of the process is undefined after a SIGFPE, SIGILL, or
     SIGSEGV signal is delivered, otherwise delivery of the signal shall
     have no effect on the process.

It isn't the signal that has the effect.  It's that the machine will
do something odd.  For example, on a Vax, an illegal memory reference
is a fault.  If the generated signal is ignored, the result is an
infinite loop.  It is useful for the OS to specify this.  On the other
hand, it is also useful for Posix to leave it undefined, because
different hardware and different OS's recover from such things
differently.

If you just do `kill -ILL 387', and process 387 has set the handler
for SIGILL to SIG_IGN, truly nothing should happen.  I believe Posix
should specify this, but I don't believe it does.

The confusion here is between the hardward (implementation-defined)
event causing the signal and the signal itself.

Your suggested fix is not adequate, however.  People should be able to
catch illegal references in programs, and then be able to exit nicely.
Your "fix" precludes doing so portably.

    -mib
--
Michael Innis Bushnell      | This is a virulent meme.  Whether or not you place
Email: [e-mail] | this into your signature file is irrelevant.  You
Phone: [phone]      | have already participated in its further trans-
              | mission, and will doubtless continue to do so.


Volume-Number: Volume 27, Number 17

From [e-mail]  Wed Feb 26 18:03:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00812; Wed, 26 Feb 92 18:03:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15417; Wed, 26 Feb 92 18:03:46 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Wed, 26 Feb 1992 22:14:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (peter da silva) writes:
>...opposition to a standard non-blocking system call interface, on the
>grounds that the threads interface provided the same functionality.
>
>For the case where threads are implemented in user mode, or as a side
>effect of threads, it's likely that most implementations will have
>some such facility anyway. Given this, I think it would be highly
>desirable to spell out a standard interface, whether or not the facility
>itself is mandated.

Except that somebody, like the clots at NIST, will then demand that
everyone implement it.  This is properly a detail of the *implementation*
of threads, and should be left to the implementors.

The point is, the user gets access to the functionality by using threads.
There is no gain to him in having another interface documented, especially
if it is one that might or might not be present, and especially if -- as
with non-blocking syscalls -- it leads to messier and buggier code
than the interface that is already provided.  (Every non-blocking-calls
program I've ever seen has had a threads program inside, screaming to
get out.)
--
The X Window system is not layered, and | Henry Spencer @ U of Toronto Zoology
it was not designed. -Shane P. McCarron |  [e-mail]  utzoo!henry


Volume-Number: Volume 27, Number 16

From [e-mail]  Fri Feb 28 19:11:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05204; Fri, 28 Feb 92 19:11:47 -0500
Received: from kithrup.COM (via [140.174.1.40]) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22749; Thu, 27 Feb 92 21:06:56 -0500
Newsgroups: comp.std.unix
From: "Mike Wulkan" <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>,
Date: Thu, 27 Feb 1992 13:28:45 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Mike Wulkan")

In article <[e-mail]>,
[e-mail] (Michael I Bushnell) writes:

>If you just do `kill -ILL 387', and process 387 has set the handler
>for SIGILL to SIG_IGN, truly nothing should happen.  I believe Posix
>should specify this, but I don't believe it does.
>
>The confusion here is between the hardware (implementation-defined)
>event causing the signal and the signal itself.
>
>Your suggested fix is not adequate, however.  People should be able to
>catch illegal references in programs, and then be able to exit nicely.
>Your "fix" precludes doing so portably.

No, my "fix" was only in reference to SIG_IGN.  You can still specify
a signal catching function and then longjmp, exit or abort "nicely".
There is nothing portable about the current Posix definition of
ignoring (via SIG_IGN) a SIGSEGV, SIGILL or SIGFPE signal since it
specifically says that the behavior of the process after the signal
is delivered is undefined.

Mike Wulkan


Volume-Number: Volume 27, Number 19

From [e-mail]  Fri Feb 28 19:12:14 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05233; Fri, 28 Feb 92 19:12:14 -0500
Received: from kithrup.COM (via [140.174.1.40]) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22838; Thu, 27 Feb 92 21:07:26 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 Feb 1992 15:12:31 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
("Mike Wulkan") writes:
>I had no question regarding additional implementation defined signals.
>My question was whether an implementation could choose to designate one
>of the other Posix defined signals as "computational" with regards to
>the undefined behaviour when returning from a handler?  I think the
>answer is no.

I agree.

>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process?

Because the event that caused the signal to be generated
has already corrupted the process's execution environment.

>Obviously the signal has an effect!

When it's ignored?

>Why not
>simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
>is done for SIGKILL and SIGSTOP?

Because the process can sometimes exit gracefully.  No
guarantee, though.

>At the very least it would seem that
>the section would be more accurately worded:
>
>  The behavior of the process is undefined after a SIGFPE, SIGILL, or
>  SIGSEGV signal is delivered, otherwise delivery of the signal shall
>  have no effect on the process.

The behavior of the process is defined after one of these
signals is delivered: abnormal termination.  The second
sentence is unnecessary, because the process of catching a
signal is already well defined.  By re-writing this, you've
removed the warning that the signals in question indicate
that the process is in trouble from which the operating
system can not rescue it.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 27, Number 20

From [e-mail]  Fri Feb 28 19:12:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05264; Fri, 28 Feb 92 19:12:47 -0500
Received: from kithrup.COM (via [140.174.1.40]) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22693; Thu, 27 Feb 92 21:06:40 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 Feb 1992 10:16:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] ("Mike Wulkan") writes:
>On a similar note, there seems to be a contradiction in the
>section describing SIG_IGN which reads:
>  "Delivery of the signal shall have no effect on the process.
>  The behavior of a process is undefined after it ignores a SIGFPE,
>  SIGILL, or SIGSEGV signal ..."
>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process?  Obviously the signal has an effect!

The first sentence states the general rule; the second then modifies it
with particular exceptions.  That in fact reflects the way the signal
mechanism evolved and the way that we think about it.

>Why not simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and
>SIGSEGV as is done for SIGKILL and SIGSTOP?

The effect as worded is to render such programs not maximally portable
anyway.  (In Standard C parlance they would be "not strictly conforming".)

In the course of preparing such standards, often there was political
pressure to "not disallow" certain examples of existing programming
practice.  Whenever the standard really could not promise semantics
for such constructs, there was the choice of forbidding them (and in
the case of the C language standard, requiring a diagnostic) or
allowing them with caveats about their non-portability.  Often the
latter was more acceptable to the standards group than the former.
I no longer recall why our signals working subgroup ended up with the
exact wording you cited, but my guess is it was partly practical
politics aimed at arriving at a consensus.

>At the very least it would seem that
>the section would be more accurately worded:
>  The behavior of the process is undefined after a SIGFPE, SIGILL, or
>  SIGSEGV signal is delivered, otherwise delivery of the signal shall
>  have no effect on the process.

The time to make such comments is during the public review of the
proposed standard.  You missed that by several years.


Volume-Number: Volume 27, Number 18

From [e-mail]  Mon Mar  2 04:15:51 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03518; Mon, 2 Mar 92 04:15:51 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18165; Mon, 2 Mar 92 04:15:49 -0500
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Fri, 28 Feb 1992 00:01:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
> The point is, the user gets access to the functionality by using threads.

Well, ignoring quality of implementation issues... yes.

> There is no gain to him in having another interface documented, especially
> if it is one that might or might not be present, and especially if -- as
> with non-blocking syscalls -- it leads to messier and buggier code
> than the interface that is already provided.

Well, actually, there is... if he's working in an environment that does not
readily lead itself to coding his program in terms of threads. For example,
if he's using an X toolkit or other non-reentrant library. In this case your
threads program is going to have to end up having one master thread that does
all the I/O, and a bunch of little threads running around it that emulate a
non-blocking syscall interface.

I understand your opinion of X, and I agree with it, but unfortunately it's
a reality, and its requirement that user application programs provide
reasonably good realtime response makes it a likely place to be doing
this sort of thing.

Also, a properly designed threads interface (I don't know if the 1003.4 one
is in a "properly designed" state or not this week) doesn't expose details
like whether the threads are managed in user mode or at the kernel level.

> (Every non-blocking-calls
> program I've ever seen has had a threads program inside, screaming to
> get out.)

How many have you seen? I've seen a lot, and some are simply written under
constraints that make threads unattractive in the extreme.

--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 27, Number 21

From [e-mail]  Mon Mar  2 04:15:58 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03551; Mon, 2 Mar 92 04:15:58 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18180; Mon, 2 Mar 92 04:15:53 -0500
Newsgroups: comp.std.unix
From: Fred Zlotnick <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 Feb 1992 19:21:16 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Fred Zlotnick)

In article <[e-mail]> [e-mail] ("Mike Wulkan") writes:
>    [ ... ]
>On a similar note, there seems to be a contradiction in the
>section describing SIG_IGN which reads:
>
>  "Delivery of the signal shall have no effect on the process.
>  The behavior of a process is undefined after it ignores a SIGFPE,
>  SIGILL, or SIGSEGV signal ..."
>
>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process?  Obviously the signal has an effect!  Why not
>simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
>is done for SIGKILL and SIGSTOP?  At the very least it would seem that
>the section would be more accurately worded:
>
The signal has no effect.  The reason the behavior is undefined is that
the process has gotten an arithmetic point exception (SIGFPE) or
has executed an illegal instruction (SIGILL) or has referenced an
address outside its address space (SIGSEGV).  After any of these
exceptions, the behavior of the process is undefined.

Of course these signals can be generated by other means, for example
through kill() or raise().  These are specifically excluded by the
standard:  The sentence quoted above ends

    ...or SIGSEGV signal that was not generated by the kill()
    function or the raise() function defined by the C Standard.

Any other event that generates one of these signals is presumably
(i.e., in a reasonable implementation) another type of exception.
----
Fred Zlotnick            |  "A standard is a treaty between the
[e-mail]        |   customer and the implementor."
...!{uupsi,ames}!mindcrf!fred     |            Henry Spencer
#include <std/disclaimer>    |


Volume-Number: Volume 27, Number 22

From [e-mail]  Mon Mar  2 04:16:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03557; Mon, 2 Mar 92 04:16:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18190; Mon, 2 Mar 92 04:15:59 -0500
Newsgroups: comp.std.unix
From: "David J. Fiander" <[e-mail]>
Subject: Weirdnix .2?
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Fri, 28 Feb 1992 16:32:27 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("David J. Fiander")

So is there such a beast?  If there is, then I have the first
entry.

According to .2D11, 'cp -R' does not have to process
subdirectories below the top level directory.  For example,
given the following structure,

  srcdir           destdir
     \
     subdir
       \
      file

a conforming cp is perfectly capable of generating the result

  srcdir           destdir
     \                \
     subdir          srcdir
       \
      file

when given the command line "cp -R srcdir destdir", without
generating any diagnostics.

Support:  POSIX.2D11 lines 3557-3564.  In particular, lines
3563-4 state "It is unspecified if cp shall attempt to copy
files in the file hierarchy rooted in source_file."


[ As far as I know, there is no Son of Weirdnix.  I like the
  idea, however:  it's been too long since we've had such a
  contest, even though the C people have one once a year 8).
  Is anybody willing to volunteer prizes? -- mod ]

Volume-Number: Volume 27, Number 23

From [e-mail]  Mon Mar  2 04:16:07 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03582; Mon, 2 Mar 92 04:16:07 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB18216; Mon, 2 Mar 92 04:16:04 -0500
Newsgroups: comp.std.unix
From: Bob Lenk <[e-mail]>
Subject: Re: return from a signal-catching function
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Fri, 28 Feb 1992 01:48:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Lenk)

In article <[e-mail]> [e-mail] ("Mike Wulkan") writes:

> On a similar note, there seems to be a contradiction in the
> section describing SIG_IGN which reads:
>
>   "Delivery of the signal shall have no effect on the process.
>   The behavior of a process is undefined after it ignores a SIGFPE,
>   SIGILL, or SIGSEGV signal ..."
>
> Why would the behavior of a process be UNDEFINED if the signal has NO
> EFFECT on the process?  Obviously the signal has an effect!

The exception that caused the signal has an effect on the process.  The
signal that it causes has no effect (because it is being ignored).  The
behavior of the process is then undefined by the standard because it
is whatever results from the exception.

>                                                              Why not
> simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
> is done for SIGKILL and SIGSTOP?

Because that was/is not existing practice.  On some specific
implementation the results of ignoring some exception may be predictable
and even useful (eg. simply continuing to execute the instruction that
follows an attempted division by zero).  There is no reason for the
standard to dictate that a non-portable application not be able to
take advantage of this.

        Bob Lenk
        [e-mail]
        {uunet,hplabs}!fc.hp.com!rml


Volume-Number: Volume 27, Number 24

From [e-mail]  Mon Mar  2 04:16:13 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03610; Mon, 2 Mar 92 04:16:13 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18230; Mon, 2 Mar 92 04:16:10 -0500
Newsgroups: comp.std.unix
From: Jan-Mark <[e-mail]>
Subject: Need help with utime().
Message-Id: <[e-mail]>
Keywords: utime
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 2 Mar 1992 08:33:44 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jan-Mark)

I have the POSIX manual 1003.1-1988 and on page 104 it states
the ``errno'' settings for a failed ``utime()'' call.

                     :
                     :
    [EACCES] Search permission is denied by a component of the path
             prefix; or the times argument is NULL and the effective
             user ID of the process does not match the owner of the
             file and write access is denied.
                     :
                     :
    [EPERM]  The times argument is not NULL and the calling process's
             effective user ID has write access to the file but does
             not match the owner of the file and the calling process
             does not have the appropriate privileges.
                     :
                     :

 So if user1 (!= root) does a ``utime()'' call on user2's file
 four things can happen (*):

                |    user1 has     |   user1 has no
            | write permission |  write permission
    ----------------+------------------+-------------------
    NULL argument   |        OK        |      EACCES
    ----------------+------------------+-------------------
     utimbuf arg.   |       EPERM      |     <undef.>


Where <undef.> means I don't know what it should be.
Is there a way of reading the 1003.1 that will give me the
proper value? Is there a post 1988 update that does so?

If you know, please let me know!


Thanks Jan-Mark.


(*) Assuming the file is not on a read-only file system, or
on a non searchable directory etc.

Volume-Number: Volume 27, Number 25

From [e-mail]  Mon Mar  2 04:23:22 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05441; Mon, 2 Mar 92 04:23:22 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18894; Mon, 2 Mar 92 04:23:19 -0500
Newsgroups: comp.std.unix
From: Robert Virding <[e-mail]>
Subject: Inconsistencies in matching betweens AWKs.
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Fri, 28 Feb 1992 16:44:21 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert Virding)

I have been implementing a set of string functions for a language
which we have developed at our lab. (Erlang, it's a real-time
concurrent high-level language for building large robust systems) As I
had need of some regular expression matching I decided to take the REs
and basic functions (match, sub, gsub and split) as defined in "The
AWK Programming Language" by Aho, Kernighan and Weinberger.

All went well until I started looking at how "awk" handles newlines
embedded in strings wrt beginning/end of string expressions. I
discovered that all the "awk"s we had acted differently. I have tried:

awk    - the old "standard" one
nawk    - a "new" one available on SUN (?), compatible with book
gawk    - GNU awk
mawk    - recently available from comp.sources.reviewed

Both gawk and mawk follow the book and conform to POSIX 1003.2 (draft
11) standard.

I enclose some small test files which show how inconsistent the
systems really are (or seem to be). Even when there were no newlines
in the string results were inconsistent. What does the standard say?
Any help would truly be appreciated.


        Robert Virding  @ Ellemtel Utvecklings AB, Stockholm
        EMAIL: [e-mail]

P.S. If there is any interest I will summarise the results.

TESTS AND RESULTS
=================

Test 1
------

A simple test which all "awk"s could do. I must admit I can't really
understand what gawk and mawk are doing. Nawk is closer to what I
think would happen. But why isn't the 'f' removed in the 2nd case?

BEGIN {
    s1 = "foobarbaz"
    n = split(s1, a1, "^.")
    print "n = " n
    for (i = 1; i <= n; i++)
        print ":" a1[i] ":"

    s2 = "foo\nbar\nbaz"
    n = split(s2, a2, "^.")
    print "n = " n
    for (i = 1; i <= n; i++)
        print ":" a2[i] ":"

    exit
}

awk        nawk        gawk        mawk

n = 1        n = 2        n = 9        n = 10
:foobarbaz:    ::        ::        ::
n = 3        :oobarbaz:    ::        ::
:foo:        n = 1        ::        ::
:bar:        :foo        ::        ::
:baz:        bar        ::        ::
        baz:        ::        ::
                ::        ::
                ::        ::
                ::        ::
                n = 9        ::
                ::        n = 12
                ::        ::
                ::        ::
                :        ::
                :        ::
                ::        ::
                ::        ::
                :        ::
                :        ::
                ::        ::
                ::        ::
                        ::
                        ::

Test 2
------

This test was impossible for awk (no gsub function). I will also admit
that nawk here seemd to do something which I feel is more reasonable.

BEGIN {
    s1 = "foobarbaz"
    gsub("^.", "X&Y", s1)
    print ":" s1 ":"

    s2 = "foo\nbar\nbaz"
    gsub("^.", "X&Y", s2)
    print ":" s2 ":"

    exit
}

nawk        gawk                mawk

:XfYoobarbaz:    :XfYXoYXoYXbYXaYXrYXbYXaYXzY:    :XfYXoYXoYXbYXaYXrYXbYXaYXzY:
:XfYoo        :XfYXoYXoY            :XfYXoYXoYX
bar        XbYXaYXrY            YXbYXaYXrYX
baz:        XbYXaYXzY:            YXbYXaYXzY:


Test 3
------

This test was impossible for awk (no match function). Mawk here seemed the
best to me. Where nawk got its RLENGTH values from I can't understand.

BEGIN {
    s1 = "foo"
    match(s1, /foo$/)
    print RSTART, RLENGTH
    print ":" substr(s1, RSTART, RLENGTH) ":"

    s2 = "foo\n\n"
    match(s2, /foo..$/)
    print RSTART, RLENGTH
    print ":" substr(s2, RSTART, RLENGTH) ":"

    exit
}

nawk            gawk            mawk

1 4            1 3            1 3
:foo:            :foo:            :foo:
1 6            0 -1            1 5
:foo            ::            :foo

:                        :

The very end


Volume-Number: Volume 27, Number 26

From [e-mail]  Tue Mar  3 08:15:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17780; Tue, 3 Mar 92 08:15:47 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12839; Tue, 3 Mar 92 08:15:45 -0500
Newsgroups: comp.std.unix
From: Jack Jansen <[e-mail]>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Mon, 2 Mar 1992 15:45:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jack Jansen)

[e-mail] (peter da silva) writes:
>Peter Collinson noted in the recent Standards Update that there was
>opposition to a standard non-blocking system call interface, on the
>grounds that the threads interface provided the same functionality.

>For the case where threads are implemented in user mode, or as a side
>effect of threads, it's likely that most implementations will have
>some such facility anyway. Given this, I think it would be highly
>desirable to spell out a standard interface, whether or not the facility
>itself is mandated.

Hmm, I don't think that this is a good idea. If Posix takes the
easy-way-out of sanctioning multiple solutions to the same problem
just a few times more the whole thing will become worthless. I know,
profiles are the magic word (and a good thing, in some cases) but if
you provide more than one way to do almost everything Posix will
become as useless a label as "user friendly".
--
--
Jack Jansen        | In Holland things are serious, but never hopeless.
[e-mail] | In Ireland things are hopeless, but never serious.
uunet!cwi.nl!jack   G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl


Volume-Number: Volume 27, Number 27

From [e-mail]  Tue Mar  3 08:15:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17787; Tue, 3 Mar 92 08:15:50 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12850; Tue, 3 Mar 92 08:15:49 -0500
Newsgroups: comp.std.unix
From: Donn Terry <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Mon, 2 Mar 1992 15:53:11 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Donn Terry)

My opinion (which is mine, but as chair I do have a little influence :-) )
is that dynamic linking could be within scope of POSIX.1.  (It might
take a PAR change, but I would personally read the current PAR to allow
it if it came from "outside" POSIX.1 originally.)

However, frequent readers of this group will be quite aware of the frequency
of flames about "invention" being done by standards bodies.   Dynamic
linking definitely falls into that category.

Of course we also get flamed for not "inventing" things.  Such is life.

In any case, dynamic linking is probably a useful area to start work on
development of several models so it can be determined what works well and
what doesn't.  (Again, remember the flames we get for inventing something
without trying it, and many of them have much more obvious solutions than
dynamic linking.)

If someone were to come forward with a proposal that had a pretty high
level of consensus, and which was feasable to implement on a broad
range of machines, specifically including those with non-traditional
architectures (i.e. not like VAXes)), then I'm sure POSIX.1 would
consider it, and determine if consensus on doing it can be reached amongst
the participants.

However, if YOU want dynamic linking (or anything else), it's YOUR job to
make it happen.  The meetings are open (but not free, unhappily...
Sugar Daddies may apply at any time.)


Donn Terry
Chair 1003.1
(Speaking only for myself.)


Volume-Number: Volume 27, Number 28

From [e-mail]  Tue Mar  3 08:15:57 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17796; Tue, 3 Mar 92 08:15:57 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12864; Tue, 3 Mar 92 08:15:54 -0500
Newsgroups: comp.std.unix
From: Bradley Wong <[e-mail]>
Subject: List of POSIX-compatible OS's?
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: TRW SEDD
Date: Mon, 2 Mar 1992 19:13:56 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bradley Wong)

Is there a fairly efficient (i.e., existing list or ??) way to
find out what vendor OS offerings are POSIX-compliant
or have announced the intention of becoming POSIX-compliant
RSN (Real Soon Now)?

Thanks,

Marc Ries
[e-mail]


Volume-Number: Volume 27, Number 29

From [e-mail]  Tue Mar  3 08:16:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17803; Tue, 3 Mar 92 08:16:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12876; Tue, 3 Mar 92 08:15:58 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: POSIX MEETING in EUROPE - OCTOBER
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Usenix Association, Standards Liaison
Date: Tue, 3 Mar 1992 00:31:27 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)


                       MEETING ANNOUNCEMENT

        IEEE TECHNICAL COMMITTEE ON OPERATING SYSTEMS (TCOS)

                           P1003 POSIX

                       OCTOBER 19-23, 1992

                             UTRECHT

The IEEE P1003 (POSIX) meeting scheduled for October 19-23, 1992 will be
held at Utrecht in the Netherlands. A major goal of this meeting is to
enable participation in the POSIX standards development process by
interested parties in Europe who may be unable to attend the meetings in
the US.  This preliminary announcement is being made now in order to
allow sufficient time for advance planning by those wishing to attend.
Specific details regarding meeting registration and schedules for
individual working groups will be made available in the future.

----------------------------------------
Posted by Peter Collinson, in my guise as Usenix standards liaison. Please
don't ask me for any more specific details. I will, however, post
some contact information nearer the time.



Volume-Number: Volume 27, Number 30

From [e-mail]  Tue Mar  3 16:13:56 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13362; Tue, 3 Mar 92 16:13:56 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23007; Tue, 3 Mar 92 16:13:50 -0500
Newsgroups: comp.std.unix
From: Bob Bagwill <[e-mail]>
Subject: Re: List of POSIX-compatible OS's?
Message-Id: <[e-mail]>
Summary: posix list
Keywords: posix
X-Submissions: [e-mail]
Organization: Computer Systems Lab
References: <[e-mail]>
Date: Tue, 3 Mar 1992 14:57:04 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Bagwill)

In article <[e-mail]> [e-mail] (Bradley Wong) writes:
>Is there a fairly efficient (i.e., existing list or ??) way to
>find out what vendor OS offerings are POSIX-compliant
>or have announced the intention of becoming POSIX-compliant
>RSN (Real Soon Now)?

To get the register of the POSIX implementations which have been tested
by an accredited POSIX testing lab by email, and whose test results
have been validated by NIST, do the following (using /usr/ucb/mail as
an example):

    mail [e-mail]
    Subject: anything
    path yourname@yournode
    send register
    end
    .

To get the testing policy, add "send policy"; to get the testing
requirements, add "send requirements".

Everyone and their clone have announced POSIX-compliancy RSN.  BFD.
--
Bob Bagwill    NIST/Computer Systems Lab/Software Engineering Group


Volume-Number: Volume 27, Number 31

From [e-mail]  Fri Mar  6 00:33:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08638; Fri, 6 Mar 92 00:33:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25162; Fri, 6 Mar 92 00:33:05 -0500
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Wed, 4 Mar 1992 18:23:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Jack Jansen) writes:
> Hmm, I don't think that this is a good idea. If Posix takes the
> easy-way-out of sanctioning multiple solutions to the same problem

I don't think this is the easy way out, nor that it's a solution to
the same problem.

The easy way out is to specify threads and let everyone continue to use
a bunch of inconsistent interfaces for a common capability if they can't
use threads for some reason (like, they have to support dusty-deck
runtimes like every X toolkit in existence).

The hard way is to define a consistent interface that can be provided
on a variety of systems, and while you're about it clean out some
of the cack in existing implementations (select/poll/O_NDELAY/...).
--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 27, Number 32

From [e-mail]  Tue Mar 10 17:07:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04058; Tue, 10 Mar 92 17:07:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18881; Tue, 10 Mar 92 17:06:58 -0500
Newsgroups: comp.std.unix
From: "David J. Fiander" <[e-mail]>
Subject: sed's r and w commands
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 10 Mar 1992 13:44:07 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("David J. Fiander")

According to D11.2,

        The r and w commands take an optional rfile (or wfile)
    parameter...

(ll 11338-9).  But nowhere does the standard describe the
behaviour of these commands when the "optional" parameter is
omitted.  In fact, the descriptions of the commands seem to
indicate that the parameter is _not_ optional, since it is not
surrounded by square brackets.

- David


Volume-Number: Volume 27, Number 32

From [e-mail]  Tue Mar 10 17:07:04 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04076; Tue, 10 Mar 92 17:07:04 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18901; Tue, 10 Mar 92 17:07:01 -0500
Newsgroups: comp.std.unix
From: "David J. Fiander" <[e-mail]>
Subject: More sed problems
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 10 Mar 1992 15:40:27 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("David J. Fiander")

According to the rationale, "The requirements for acceptance of
<blank>s and <space>s in command lines has been made more
explicit..."

Does that mean that I should only strip blanks preceeding
addresses and between addresses and commands?  If so, does that
mean that

$a\
     boo!

will append '     boo!' to the end of the file, even though this
goes against historical practice?

It is obvious that

$a\
\     boo!

will still behave the same way, since the description of _text_
works out, but nothing has been said about leading spaces in
_text_ lines.

--
David J. Fiander          |EXAMPLES:  'sed 10q file' -- Print the first 10
<[e-mail]>          |lines of a file.  Some systems call this
Mortice Kern Systems Inc. |function _head_.
Waterloo, Ontario, Canada |       - tail(1) man page from Research UNIX


Volume-Number: Volume 27, Number 33

From [e-mail]  Tue Mar 10 17:07:09 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04099; Tue, 10 Mar 92 17:07:09 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18927; Tue, 10 Mar 92 17:07:06 -0500
Newsgroups: comp.std.unix
From: J Lee Jaap <[e-mail]>
Subject: Re: List of POSIX-compatible OS's?
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: AS&M Inc
References: <[e-mail]> <[e-mail]>
Date: Tue, 10 Mar 1992 20:56:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (J Lee Jaap)

In article <[e-mail]> [e-mail] (Bob Bagwill) writes:
>To get the testing policy, add "send policy"; to get the testing
>requirements, add "send requirements".
------->                 ^^^^^^^^^^^^

That should be "send required".

--
J Lee Jaap <[e-mail]> {+1 804/864, or FTS 928}-2148
employed by, not speaking for, AS&M Inc, at NASA LaRC, Hampton VA 23665-5225


Volume-Number: Volume 27, Number 34

From [e-mail]  Thu Mar 19 18:39:58 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15419; Thu, 19 Mar 92 18:39:58 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23914; Thu, 19 Mar 92 18:39:47 -0500
Newsgroups: comp.std.unix
From: Scott Thomas <[e-mail]>
Subject: Summary of XTI responses
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: XTI TLI
Nntp-Posting-Host: ftp.uu.net
Reply-To: Scott Thomas <[e-mail]>
X-Submissions: [e-mail]
Organization: Hughes Aircraft Company
Date: Thu, 19 Mar 1992 21:31:26 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scott Thomas)

Hello,
A while back I posted a request for info on X/Open's XTI API
standard.  I apologize for the delay in posting this, but we
have other deadlines.  The responses were not as plentiful
as I had hoped, but the few I did receive were helpful.  Many
thanks to Joel Spencer of Bull Worldwide Information Systems,
who was especially helpful.

--
Scott Thomas

Space & Communications Group
Hughes Aircraft Co.
  (fax) 703-438-8430
(email) [e-mail]


-------------------- cut here --------------------------------


From: [e-mail] (Joel Spencer)
Subject: Re: X/Open's XTI standard & OSF's TLI standard
Newsgroups: comp.std.unix
Organization: Bull World Wide Information Systems Inc.

( Joel Spencer faxed a copy of the DPX & DPX/2 reference manual
  appendix from BULL Info. Systems.  The appendix briefly discusses
  the differences between XTI & TLI.  Below is a short summary of
  the appendix, most of which I quoted. )

    XTI is based on the SVID Issue 2, Volume 3, Networking
    Services Extensions.  XTI provides refinement of the Transport
    Level Interface where such refinement is considered necessary.
    This refinement includes:
        - additional commentary ...
        - modifications to the interface ...
        - removal of dependencies on specific UNIX verisons ...

    The following features can be considered XTI extensions to TLI:
        - Some functions may return more error types ...
        - transport provider identifier has been generalised ...
        - additional events have been defined ...
        - additional features added to t_snd(), t_sndrel(), t_rcvrel()
        - can use options for certain types of transport service
        - O_RDONLY & O_WRONLY flags usage withdrawn
        - XTI checks value of 'qlen' and prevents applications
          waiting forever on 't_listen()' calls

( Joel also answered a few questions, which I included the responses to. )

>>
>> Does the document mention how to obtain XTI?  If not, could you please
>> tell me?  As a user, do you prefer XTI over TLI?
>>

>
> i do not think that XTI is a public domain item.  certainly the stuff that
> i work on is an "orderable" item with a market id(CNDG001-CB00) and a
> price.  the documentation set is also a separately orderable
> item.  i do not know who your UNIX vendors are, but you may be able
> to oreder a copy of XTI from them.  then again, from feedback that
> i have gotten, the Bull UNIX XTI release is one of the first available.
>
> as a user i prefer XTI.  the documentation is better.  and i know it will
> be around for a while because it is sanctioned by X/Open.  i do not
> think TLI will have as many users as XTI.  but only time will tell.
>
========================================================================

From: [e-mail] (Simon Patience)
Subject: Re: X/Open's XTI standard & OSF's TLI standard

One piece of information for you. The TLI interface is in fact a product of
AT&T and not OSF. It is what X/Open based XTI (which OSF supports) on.

Simon.

  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                    uunet!gr.osf.org!sp

========================================================================

From: [e-mail] (Matthew Caprile)
Subject: X/Open's XTI standard & OSF's TLI standard

XTI is described in voume 7 of the X/Open Portability Guide, issue 3 (XPG3).
The ISBN number is 0-13-685892-9. You can walk into any decent bookstore
and have them order it (it is published by Prentice Hall). Or you can go
to a computer-specialist bookstore and ask them if they have it in stock.

It is supposed to be a transport-level independant networking interface
(You are supposed to be able to write apps that will work over both
ISO and TCP/IP stacks, not caring which one is used).

You might want to contact X/Open directly to see if they have published
anything on XTI since XPG3 came out.

  X/Open Company Limited
  Apex Plaza, Forbury Road
  Reading, England, RG1 1AX
  Tel: +(44) (0)734 508311 x2230

      -or-

  X/Open Company Ltd
  1010 El Camino Real, Suite 380
  Menlo Park, CA 94025
  Phone: [phone]
  FAX:   [phone]


========================================================================


Volume-Number: Volume 27, Number 35

From [e-mail]  Fri Mar 20 18:22:44 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13023; Fri, 20 Mar 92 18:22:44 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12249; Fri, 20 Mar 92 18:22:35 -0500
Newsgroups: comp.std.unix
From: "Brian R. Haug" <[e-mail]>
Subject: seekdir/rewinddir on non seekable file systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: NCR Corp
Date: Fri, 20 Mar 1992 22:12:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Brian R. Haug")

I've recently encountered a problem with seekdir in that it does not work
when the directory is on a device incapable of seeking (like the /dev/fd
filesystem in SVR4) because seekdir calls lseek which fails.  I realize that
seekdir is no part of POSIX, but we have to be compatible with SVID and X/OPEN
too.

Basicly, I'm interested in hearing what other people think about this "problem."
POSIX seems to have done a good job covering all the bases, as it does not
allow chroot, which would prevent re-opening the file to implement rewinddir.
Unfortunately, SVID and X/OPEN allow chroot.  And, of course, neither
rewinddir nor seekdir returns values to indicate failure.

Comments about the standard, problem, or proposed solutions would be greatly
appreciated.

            Share and Enjoy!

                  Brian


Volume-Number: Volume 27, Number 36

From [e-mail]  Sat Mar 21 18:53:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA29562; Sat, 21 Mar 92 18:53:32 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02840; Sat, 21 Mar 92 18:53:22 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]>
Date: Sat, 21 Mar 1992 19:31:46 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]>
[e-mail] ("Brian R. Haug") writes:
>I've recently encountered a problem with seekdir in that it does not work
>when the directory is on a device incapable of seeking (like the /dev/fd
>filesystem in SVR4) because seekdir calls lseek which fails.

Then I guess you'll have to convert the directory into a seekable
form, perhaps by copying it into memory.

>POSIX seems to have done a good job covering all the bases, as it does not
>allow chroot, which would prevent re-opening the file to implement rewinddir.

If you cache the directory, all it takes is a pointer assignment.
POSIX doesn't require that you maintain cache consistency on
the directory image, either.

Are you saying that SVID and XPG3 require that an open directory
stream remain useful after a call to chroot() that would make
the directory itself inaccessible?

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 27, Number 37

From [e-mail]  Mon Mar 23 18:27:24 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24983; Mon, 23 Mar 92 18:27:24 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21365; Mon, 23 Mar 92 18:27:16 -0500
Newsgroups: comp.std.unix
From: "Brian R. Haug" <[e-mail]>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: NCR Corp
References: <[e-mail]> <[e-mail]>
Date: Mon, 23 Mar 1992 14:10:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Brian R. Haug")

In article <[e-mail]> [e-mail]
(Chuck Karish) writes:
>In article <[e-mail]> I wrote
>>I've recently encountered a problem with seekdir in that it does not work
>>when the directory is on a device incapable of seeking (like the /dev/fd
>>filesystem in SVR4) because seekdir calls lseek which fails.
>
>Then I guess you'll have to convert the directory into a seekable
>form, perhaps by copying it into memory.

This was considered, but was not acceptable for two reasons:
1)  rewinddir is implemented as a call to seekdir, and POSIX requires
    rewinddir to "refer to the current state of the corresponding
    directory, as a call to opendir() would have done."  See 5.1.2.2
    lines 51-54.  This puts me back at square one again with regard
    to seeking.  I probably should have made the rewinddir point
    better in my original post.
2)  The directory could be huge, allocating a megabyte, or even several K
    of memory was deemed inappropriate for our implementation.

>>POSIX seems to have done a good job covering all the bases, as it does not
>>allow chroot, which would prevent re-opening the file to implement rewinddir.
>
>If you cache the directory, all it takes is a pointer assignment.
>POSIX doesn't require that you maintain cache consistency on
>the directory image, either.

Unless I've mis-understood what you're saying here, I have to disagree, see
the section of the standard mentioned earlier.

>Are you saying that SVID and XPG3 require that an open directory
>stream remain useful after a call to chroot() that would make
>the directory itself inaccessible?

That's my interpretation.  Granted you can not open any of the files
that you find in that directory, but I should still be able to access
the directory (until closedir is called).  After all, I can access files
not available from the current root directory IF I had them open before
the chroot call.  Seems like the same idea to me.

Knowing your reputation, I appreciate you taking time to respond.  I
think you've helped me better explain the problems we perceive.



Volume-Number: Volume 27, Number 38

From [e-mail]  Tue Mar 24 00:01:54 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04780; Tue, 24 Mar 92 00:01:54 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23482; Tue, 24 Mar 92 00:01:43 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Tue, 24 Mar 1992 03:59:52 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] ("Brian R. Haug") writes:
>I've recently encountered a problem with seekdir in that it does not work
>when the directory is on a device incapable of seeking (like the /dev/fd
>filesystem in SVR4) because seekdir calls lseek which fails.  I realize that
>seekdir is no part of POSIX, but we have to be compatible with SVID and X/OPEN
>too.

I was intimately involved in the 1003.1 specification for the directory
access functions, and also implemented a widely used more-or-less portable
version of these functions (including seekdir()/telldir()) that among
other things served as the basis of the version shipped with UNIX System V.
I mention this to assure you of my familiarity with the problems..

The reason that 1003.1 did NOT specify seekdir()/telldir() is that there
simply is no way to guarantee that these can be correctly implemented in
all reasonable environments.  All versions I have seen (including mine)
depend on filesystem behavior that is by no means guaranteed, and as you
have discovered this problem has gotten worse as evolution has proceeded.
My copies of SVID and XPG are not at hand as I write this, but if they are
currently insisting on reliable seekdir()/telldir() they need to be fixed.

rewinddir() is more important, because it IS required by 1003.1.  The only
way I know of to implement it on a system that doesn't support lseek() to
the beginning (only!) of an open directory is to record the full pathname
at opendir() time and use this information to reopen the directory (after
closing the current fd).  As you observe, chroot() could cause this to
fail, which is not a problem for POSIX but would be for other UNIX
standards.  Are you sure that /dev/fd cannot be lseek()ed even to its
beginning?  That would seem to be a severe deficiency in the implementation
of that filesystem.  Assuming /dev/fd cannot be fixed, then I'd suggest
that SVID/XPG/etc. exempt rewinddir() from being used (in conforming
applications) after a chroot().  (chroot() opens a large can of worms, and
might be better left out of UNIX application interface standards.)


Volume-Number: Volume 27, Number 39

From [e-mail]  Wed Mar 25 17:23:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10086; Wed, 25 Mar 92 17:23:42 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29763; Wed, 25 Mar 92 17:23:38 -0500
Newsgroups: comp.std.unix
From: "Brian R. Haug" <[e-mail]>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: NCR Corp
References: <[e-mail]> <[e-mail]>
Date: Wed, 25 Mar 1992 21:39:03 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Brian R. Haug")

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>Submitted-by: [e-mail] (Doug Gwyn)
>
>rewinddir() is more important, because it IS required by 1003.1.  The only
>way I know of to implement it on a system that doesn't support lseek() to
>the beginning (only!) of an open directory is to record the full pathname
>at opendir() time and use this information to reopen the directory (after
>closing the current fd).

A co-worker suggested that perhaps the real problem is that rewinddir and
seekdir are of type void and should have some other type so that they may
return an error condition (like the one I'm having to deal with).

When Andy Tannenbaum (sp?) remarked "Standards are wonderful, there are so
many to choose from."  He obviously was not in the implementor's shoes!

            Share and Enjoy!

                  Brian


Volume-Number: Volume 27, Number 40

From [e-mail]  Wed Mar 25 19:20:47 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14922; Wed, 25 Mar 92 19:20:47 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01557; Wed, 25 Mar 92 19:20:45 -0500
Newsgroups: comp.std.unix
From: Johann Haider <[e-mail]>
Subject: awk should deal with hexadecimal numbers
Message-Id: <[e-mail]>
Summary: awk is lacking functionality to deal with numbers other than decimal
Originator: [e-mail]
Keywords: awk posix hexadecimal
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Technical University of Vienna
Date: Wed, 25 Mar 1992 22:16:42 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Johann Haider)

Hello all,
I read in the distribution of Mawk that there is a posix draft
( posix1003.2 draft(11.2) ) of awk, therefore I hope this article
isn't totally misplaced :-)

After I had used awk for some time some years ago I had the problem
to parse the output of `nm' which is in hexadecimal on that platform.
I had to write a filter program in C to convert the hex addresses to
decimal and do the parsing afterwards.

When Gnu awk came along I addeed a new function strtol() to convert
arbitrary base numbers to decimal.

As I consider this function very useful, I think it should be added to
the standard or at least it should not be omitted from the standard
without being discussed.

If someone is in the posix comitee and such a function has been abandoned
already I would be glad to hear about it.

Thank you
Hans

--
Johann Haider                               Rehabilitation Engineering Group
Institute for Electronics               Technical University Vienna, Austria
Email: [e-mail]                     phone:  [phone]

[ In general, comp.std.unix (or the std-unix-list mailing list) is not
  the right place to work on the POSIX standard(s).  It is a good place
  for *discussion*, however, which is why I've posted this.  -- mod ]

Volume-Number: Volume 27, Number 41

From [e-mail]  Thu Mar 26 16:27:01 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23823; Thu, 26 Mar 92 16:27:01 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14358; Thu, 26 Mar 92 16:26:57 -0500
Newsgroups: comp.std.unix
From: Bob Robillard <[e-mail]>
Subject: Call for Input for 1003.7
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Thu, 26 Mar 1992 20:18:36 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Robillard)

[ Responses can go to Jeff Parker or to the poster, Bob Robillard
  ([e-mail]) ]

    I'm writing on behalf of POSIX 1003.7.  We are looking for examples
of existing practice in User and Group Management, and we would like to
invite your company to submit either existing products or requirements.
We are hope to describe an API for distributed user management, but we
would be happy to consider existing practice that illuminates the problem.

Our next meeting is in Dallas the week of April 6-10th.  I will convey
any documents that reach me before then.  We also welcome any representation
you may be able to provide.

Jeff Parker, POSIX 1003.7, Sun Microsystems
[e-mail]

Volume-Number: Volume 27, Number 42

From [e-mail]  Fri Mar 27 23:47:48 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21455; Fri, 27 Mar 92 23:47:48 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18907; Fri, 27 Mar 92 23:47:55 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: P1003.4[a] Common Reference Ballots (CRBs)
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Fri, 27 Mar 1992 15:27:24 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

Please be advised that this week a small group of people from
OSF, USL and other organizations met and drafted the CRBs
for P1003.4 (Realtime) and P1003.4a (pthreads).  The .4 CRB
will be published Tuesday March 31st and the .4a CRB will
be published Monday April 13th.  Ballots are due at the IEEE
office April 8th and May 1st respectively.

The CRB represents a consensus of the CRB group and we hope you
will read and consider endorsing the objections submitted in the CRBs.

Thanks Much.


Volume-Number: Volume 27, Number 43

From [e-mail]  Sat Mar 28 08:42:27 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23024; Sat, 28 Mar 92 08:42:27 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09449; Sat, 28 Mar 92 08:42:29 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: awk should deal with hexadecimal numbers
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Fri, 27 Mar 1992 21:18:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

>Submitted-by: [e-mail] (Johann Haider)
>As I consider this function very useful, I think it should be added to
>the standard or at least it should not be omitted from the standard
>without being discussed.

It is, unfortunately, rather too late for this.  1003.2, which covers
awk among many other things, is pretty much finalized.

It *is* a blemish that awk can do various kinds of conversions *to*
strings using sprintf, but can't go the other way very easily.
--
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  [e-mail]  utzoo!henry


Volume-Number: Volume 27, Number 44

From [e-mail]  Sat Mar 28 08:42:31 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23031; Sat, 28 Mar 92 08:42:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09461; Sat, 28 Mar 92 08:42:32 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 27 Mar 1992 17:05:50 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] ("Brian R. Haug") writes:
>A co-worker suggested that perhaps the real problem is that rewinddir and
>seekdir are of type void and should have some other type so that they may
>return an error condition (like the one I'm having to deal with).

I agree that it was unfortunate, but it wouldn't solve the REAL problem
(from the point of view of the application program), which is that the
rewinddir() fails under perfectly ordinary usage.  As I recall the P1003
discussions, the opinion was generally held that if opendir() succeeded,
then a subsequent rewinddir() couldn't possibly fail (except if the
filesystem went off line or something of the sort, which we weren't
particularly concerned about at the time).  seekdir(), on the other hand,
was expected to malfunction using any reasonable user-mode implementation,
on certain systems that dynamically compact directories.  (Of course they
would also affect readdir(), but only in the sense of causing some entries
to be skipped.  Really, the file-system part of the operating system should
provide more reliable directory access facilities than UNIX typically does.)

My honest suggestion is to get the /dev/fd filesystem maintainer to support
seeking to BOF at least, if not providing seek in its full generality.


Volume-Number: Volume 27, Number 45

From [e-mail]  Mon Mar 30 20:18:20 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12153; Mon, 30 Mar 92 20:18:20 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24374; Mon, 30 Mar 92 20:18:27 -0500
Newsgroups: comp.std.unix
From: Arnold Robbins <[e-mail]>
Subject: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Georgia Institute of Technology
Date: Mon, 30 Mar 1992 14:59:47 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Arnold Robbins)

Could someone familiar with 1003.2a (the UPE - User Portability Extension)
answer the following question for me?

What does

    echo a # b c

produce if typed at an interactive shell?  There is one sh-style shell out
in the wide world that will echo 'a # b c' instead of just 'a' and I'd like
to know if this behavior is POSIX-compiliant.

Thanks,
--
Arnold Robbins --- College of Computing            | Laundry increases
Georgia Tech, Atlanta, GA 30332-0280            | exponentially in the
Domain: [e-mail]     Phone: [phone] | number of children.
UUCP: uunet!cc.gatech.edu!arnold FAX:   [phone] |  -- Miriam Robbins


Volume-Number: Volume 27, Number 46

From [e-mail]  Mon Mar 30 22:26:35 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17403; Mon, 30 Mar 92 22:26:35 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22482; Mon, 30 Mar 92 22:26:43 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
References: <[e-mail]>
Date: Tue, 31 Mar 1992 02:09:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David J. MacKenzie)

> Could someone familiar with 1003.2a (the UPE - User Portability Extension)
> answer the following question for me?

> What does

>     echo a # b c

> produce if typed at an interactive shell?  There is one sh-style shell out
> in the wide world that will echo 'a # b c' instead of just 'a' and I'd like
> to know if this behavior is POSIX-compiliant.

The only explicit mention of `#' for the shell in p1003.2a is in the
description of the Vi editing mode.  It's a command to comment-out the
current line (excerpted below).  Read strictly, it doesn't appear to
say anything about what happens when the user types a `#' as part of a
command, only what happens when the shell inserts a `#' in response to
a special command.  Read more loosely, it requires that `#' at the
beginning of a line begin a comment, but doesn't explicitly say
anything about `#' in the middle of a line.  Read more loosely still,
it specifies that `#' introduces a comment in interactive shells.

Perhaps I missed an implicit or blanket reference somewhere to how
non-interactive comments affect interactive shells, which would affect
the above analysis.  If not, POSIX.2a doesn't precisely say whether or
not that shell's behavior is compilant, so I suppose that it is.


 4.56.7.5  Vi Line Editing Command Mode
 . . .
 The following commands shall be recognized in command mode:
 . . .
    #            Insert the character # at the beginning of the current
                 command line and treat the current command line as a
                 comment.  This line shall be entered into the command      8
                 history; see 5.12.                                         8

--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 27, Number 47

From [e-mail]  Tue Mar 31 15:53:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18365; Tue, 31 Mar 92 15:53:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29086; Tue, 31 Mar 92 15:53:07 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Tue, 31 Mar 1992 11:27:37 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (David J. MacKenzie) writes:
>The only explicit mention of `#' for the shell in p1003.2a is in the
>description of the Vi editing mode.  It's a command to comment-out the
>current line (excerpted below).  ...

That's disgusting!
If 1003.2 is going to break zillions of existing carefuly-written shell
scripts, then it ought not to be adopted.


Volume-Number: Volume 27, Number 48

From [e-mail]  Tue Mar 31 15:53:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18366; Tue, 31 Mar 92 15:53:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29048; Tue, 31 Mar 92 15:53:02 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <mks!stephe>
Subject: EurOpen Report on POSIX, Jan '92
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 31 Mar 1992 16:33:45 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)



           Report on the January 1992 IEEE POSIX Meeting for EurOpen
                       Stephen R. Walli <[e-mail]>
                      EurOpen Institutional Representative


          Standing  on Huntington  Beach,  gazing across  the  moonlit
          Pacific  after  a  five  hour  Sponsor  Executive  Committee
          meeting, is a  small group of  POSIX refugees.  It is 10 pm.
          The  oil  rigs  glow  golden  in  the  distance  like  great
          Christmas trees.  The surf crashes and hisses at our feet.

          Jason:  Just  remember,  Stephe,  in  the  grand  scheme  of
          things....

          Stephe [interrupting]: ...Oil's important.

          Okay. So  I'm  a cynic.  It  was generally  an ugly week.  I
          believe  there  are  still  some  fundamental flaws  in  the
          structure  of  POSIX.   Working  group  members   are  still
          grappling with  the  enormity of  the  beast we've  created.
          GUIs, rescued from  the jaws of defeat by the IEEE Standards
          Advisory Board,  entered the scene  again. Life (and  POSIX)
          goes on.

          1.  POSIX is coming! POSIX is coming!

          The IEEE  POSIX  working groups ARE  coming to Europe.  This
          Autumn, the POSIX working groups will be meeting in Utrecht,
          NL, from  October 19-23.  The meetings will  be held at  the
          Holiday Inn and the Scandic Crown Hotel.

          Information will be  posted to this  column, and on  the net
          where appropriate, as the meetings approach.

          There will  also be an  ISO Working Group  15 (WG15 --  ISO
          POSIX) meeting around  the same time.  It will either be the
          week before or  the week after,  and will also be in Europe.
          Again, information will be forthcoming.

          2.  SICC and the PMC

          POSIX often  makes  use of  the fact that  a small group  of
          people can  go off  and accomplish what  a large group  will
          spend hours  arguing  about. Small  committees are the  work
          method  of  choice  in many  areas.  Two committees  of  the
          Sponsor Executive Committee  (SEC) are the System Interfaces
          Co-ordination Committee (SICC),  and the Project  Management
          Committee (PMC).

          SICC is gaining  momentum. It is  effectively the chairs  of
          all the system interface groups:
          -- POSIX.1, the base system interface,
          -- POSIX.4, real-time extensions to POSIX.1,
          -- POSIX.6, security extensions to POSIX.1,
          -- POSIX.8, transparent file access extensions to POSIX.1,
          -- POSIX.12,  protocol  independent   interfaces  (Berkeley
            sockets and X/Open's TLI).
          -- POSIX.15, supercomputing batch interfaces,
          -- POSIX.17, directory services (think X.500).

          They are  a simple  subcommittee of the  SEC, that meets  to
          resolve areas of conflict between the base standards, and to
          work out concerns which affect all of the documents.

          The other group  which is effecting  the way POSIX is coming
          forward is the  Project Management Committee (PMC). This was
          the fourth  meeting  the PMC  has existed,  and half of  its
          eight members  were due  to retire. Two  elected to stay  on
          (and were voted  back in by  the SEC) for  an additional two
          year  term.  Two  new  members  (one  of  them  the  EurOpen
          Institutional  Representative,)  were  also voted  into  the
          group.

          The PMC  is responsible for  mentoring existing projects  to
          ensure they are  performing according to plan. They are also
          responsible for  ensuring that  new project requests  (PARs)
          are complete and  have all the  attendant paper work  before
          reaching the SEC.

          One interesting  result  of their  work  this week  was  the
          splitting up of the POSIX.7 (System Administration) project.
          POSIX.7 has been re-organized into:
          -- a parent project (POSIX.7), which is responsible for co-
            ordinating the other parts of the POSIX.7 standard
          -- POSIX.7a to build a standard for print management,
          -- POSIX.7b to build a standard for software management,
          -- POSIX.7c to a set of guidelines for user management.

          The final subproject  is important. There  is not sufficient
          agreement  on  how  to do  user  administration to  build  a
          standard.  There  is   a  lot  of   existing  practice  with
          administering  users.  Everyone   agrees  that  the  current
          solutions are not good. So they are building a set of agreed
          upon guidelines. It's  really too bad  the PMC didn't  exist
          when other project requests were cut to suggest this sort of
          solution for  certain  other contentious  immature areas  of
          technology.

          3.  Multi-lingual Test Assertions

          Multi-lingual Test Assertions are test assertions written in
          such  a  way   that  test  suites  in  multiple  programming
          languages  could be  written.  This addresses  the  problems
          associated with  testing conformance  for something like  an
          Ada run-time  environment,  that supports  POSIX.5 (the  Ada
          language version  of  POSIX.1 functionality,)  when all  the
          test suites are written in C.

          POSIX describes an  interface to operating  system services.
          It is  based  on the  historical  C interface  to UNIX,  but
          should not  be  restricted to  just  that language.  No  one
          wants  to  make  the  same  mistakes  made with  GKS  (which
          demonstrated  you  could   write  Fortran  programs  in  any
          language,) by forcing other languages to bind the interfaces
          in the same functional way.

          This  was  why  ISO WG15  (ISO  POSIX) wants  a  programming
          language independent specification to be written of POSIX.1.
          Other   languages   can    then   bind   the   functionality
          appropriately. The semantic  description would be  kept in a
          single book, with the appropriate syntactic binding and glue
          in other books.

          Test  assertions written  to  POSIX.1 demonstrate  the  same
          problems.  Everyone  agrees  that  much  of  the  functional
          content of the  test methods for  POSIX.1 should be the same
          no matter what  programming language is  being used to write
          the suite.  If the test assertions from which the test cases
          are  built   were  written   to  the  programming   language
          independent version of  the standard, they could be bound to
          the language  syntax  at the  same  time as  the  functional
          specification, providing a  language based set of assertions
          from which to build the conformance test suite.

          Okay. The  cat's out  of the bag.  We are really  discussing
          language independent  specification  test assertions.  If  I
          used that  as  the title  to  this section,  you might  have
          turned the page.  Hopefully, you now at least appreciate the
          problem to be  solved, even if  you still run screaming into
          the night.

          Now all  we have to  do is solve  the resource problem,  and
          find people to help with the specification.

          4.  Distributed Security Study Group

          A group  of  about twenty  people met for  a day during  the
          January  POSIX  meeting   to  discuss  distributed  security
          technologies and scenarios. The group felt it had sufficient
          momentum and manpower to form a proper study group, and they
          will  meet for  the  entire week  at  the April  meeting  in
          Dallas, TX.

          They were a little disorganized to begin with, but agreed to
          a set  of  existing specifications and  models they wish  to
          begin investigating at the next meeting.

          There are those within the group that wish to take some time
          to  investigate  the   current  base  of  experience  before
          proceeding,  while   others  appear  to   want  to  pick   a
          specification and begin  tweaking it into a standard. Pretty
          aggressive considering  they haven't  cut a project  request
          yet!

          5.  PAR Wars II -- The Umpire Strikes Back

          Since we  last  looked in  on  our story, our  protagonists,
          OSF/Motif  and  Open  Look  (sometimes  known as  Rodan  and
          Godzilla) were off  chasing their project requests (PARs) up
          the IEEE Standards hierarchy. Having been told ``no'' by the
          Sponsor Executive Committee  (SEC), they are  now asking for
          sponsorship  at  the  higher  level  of the  IEEE  Standards
          Advisory Board (SAB).

          You will recall the flow.
          -- April 1991,  the  PARs first surface.  The intent is  to
            directly  form  ballot   groups  to  ballot   the  current
            programmers   and   users   guides.   The   SEC,   clearly
            uncomfortable with the  obvious overlap between  these two
            GUI PARs and the current work in P1201, argues for several
            hours (!) and then tables discussion at that time.

          -- July 1991, discussion is re-opened. A small committee is
            formed to  clearly  state all  pros  and cons  of the  two
            projects. The presentation  is made, and since all members
            of the  SEC  find at  least one  serious problem with  the
            Motif and  Open  Look project  requests, the projects  are
            voted down.

            Some were concerned  over the apparent lack of maturity of
            the  technology.    No   one  that   has  tried  the   two
            technologies (with  the exception  of the PAR  presenters)
            seems  to  like  either  of  the  interfaces.  People  are
            concerned that  wrapping a standard  around them now  will
            prevent them  from being improved  and matured. Some  user
            representatives clearly wish  there to be a single unified
            standard.

            With the apparent ``death'' of the two competing PARs came
            a motion  to  remove sponsorship  from the existing  P1201
            project, arguing it  suffers the same flaws. Discussion is
            tabled to  the  project management  committee (PMC)  until
            October.

          -- October 1991,  P1201 is allowed  to survive. P1201.1  is
            making good progress  at defining a higher level interface
            for simple  windowing,  based on  current practice.  While
            possibly not  as  functional as either  the Motif or  Open
            Look  toolkits,  it   is  useful  to   a  wide  range   of
            applications, and  there is  consensus forming around  it.
            P1201.2 is  preparing a  recommended practice document  on
            windowing style, and is making good progress.

            The  Motif  and  Open  Look  projects presenters  are  off
            haunting other corridors  (SAB).  The SAB, pointing to the
            802 LAN standards  as if they were a ``good'' example, has
            said it  is  an insufficient  reason  to kill the  project
            requests simply because they have overlapping scopes.

          The SEC is  responsible for approving  projects for the IEEE
          Technical  Committee  on  Operating  Systems  --  Standards
          Subcommittee (TCOS-SS).  This  is where  POSIX  and the  GUI
          standards all reside.

          It seems  the  SAB is  sympathetic to  their plight and  has
          agreed to  sponsor  the projects.  Gone are the  contentious
          ideas that the  two camps will  directly form ballot  groups
          and  ballot the  current  programmers references  and  users
          guides.  The SAB has said that they must play fair, and play
          by the rules.  (Direct balloting only  exists on paper  as a
          method of fast-tracking clearly uncontentious documents.)

          The SAB has  further offered them  BACK to TCOS-SS/SEC!  The
          projects really DO  belong within the scope of TCOS. The SEC
          agreed to take  a look at the revised sponsored-in-principle
          projects at the  April 1992 meeting.  I believe one member's
          phrase was to  ``accept the pig  in a poke  now, and rip the
          bag off later.''   Hopefully, it won't  be too prophetic  an
          analogy.

          We have been  cautioned that we  can not trivially  agree to
          accept them, then  shut them down. They have been sponsored-
          in-principle  by  a higher  power.   The two  projects  have
          already each  held their first  meetings, outside of  TCOS's
          sphere of influence.

          I for  one  want to see  them really play  by the rules!  If
          accepted  by  TCOS,  they  should  certainly come  into  the
          Steering  Committee  on  Windowing User  Interfaces  (SCWUI)
          realm of  influence.  No reason  to  exempt them  from  test
          assertions either.

          Language  independent  specifications  (LIS)  are  certainly
          appropriate considering  the number  of Ada developers  that
          currently need to find messy solutions to working with these
          two GUIs in  their native Ada environments. Indeed, they may
          discover that they  functionally overlap more than they care
          to admit by  writing the LIS.   If they rationalize the LIS,
          as POSIX.12 is  doing with C-based  sockets and C-based XTI,
          then maybe  Ada  could benefit  by coming  up with a  single
          binding standard!

          Of course,  if  they were  to  come forward  as  recommended
          practices or guidelines,  instead of as  full use standards,
          they would not  need to provide  LIS and test  assertions as
          robustness proofs.  Something to think about.

          As  I  said  at  the  end of  the  last report,  ``thus  are
          standards born.''



Volume-Number: Volume 27, Number 49

From [e-mail]  Tue Mar 31 16:26:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22174; Tue, 31 Mar 92 16:26:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07916; Tue, 31 Mar 92 16:26:24 -0500
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Tue, 31 Mar 1992 15:51:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

What is P1003.2a doing specifying the behaviour of vi-mode command line
editing in the first place? Is it specifying that "the shell" be ksh?
[ Or bash -- mod ]

--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"

Volume-Number: Volume 27, Number 50

From [e-mail]  Wed Apr  1 21:58:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26676; Wed, 1 Apr 92 21:58:47 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28406; Wed, 1 Apr 92 21:58:55 -0500
Newsgroups: comp.std.unix
From: Chet Ramey <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Case Western Reserve University
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 31 Mar 1992 22:53:07 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chet Ramey)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:

>What is P1003.2a doing specifying the behaviour of vi-mode command line
>editing in the first place? Is it specifying that "the shell" be ksh?

Yes, to a degree.  1003.2a specifies a subset of ksh.  The `base document'
is Bolsky & Korn's book.  The term `only one historical implementation' is
used frequently.  Things are specified exactly as ksh implements them.

Here's a sample quote:

``The KornShell version was adopted to be consistent with all the other
  KornShell features in POSIX.2, such as command-line editing.''

Chet
--
``The use of history as therapy means the corruption of history as history.''
    -- Arthur Schlesinger

Chet Ramey, Case Western Reserve University    Internet: [e-mail]


Volume-Number: Volume 27, Number 51

From [e-mail]  Wed Apr  1 21:58:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26683; Wed, 1 Apr 92 21:58:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28426; Wed, 1 Apr 92 21:58:59 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
References: <[e-mail]>
Date: Wed, 1 Apr 1992 05:25:32 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David J. MacKenzie)

> Perhaps I missed an implicit or blanket reference somewhere to how
> non-interactive comments affect interactive shells, which would affect
> the above analysis.  If not, POSIX.2a doesn't precisely say whether or
> not that shell's behavior is compilant, so I suppose that it is.

It appears that I did miss something -- any behavior that P1003.2a
doesn't specify as being different for interactive operation is the
same as for non-interactive operation.  So interactive comments need
to work the same way as non-interactive comments.  In other words,
"that shell" (bash) doesn't comply with 1003.2a in its handling of
interactive comments.

Sorry for my hasty analysis.
--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 27, Number 52

From [e-mail]  Wed Apr  1 21:58:58 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26692; Wed, 1 Apr 92 21:58:58 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28458; Wed, 1 Apr 92 21:59:05 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
References: <[e-mail]>
Date: Wed, 1 Apr 1992 05:28:18 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David J. MacKenzie)

>>The only explicit mention of `#' for the shell in p1003.2a is in the
>>description of the Vi editing mode.  It's a command to comment-out the
>>current line (excerpted below).  ...

> That's disgusting!
> If 1003.2 is going to break zillions of existing carefuly-written shell
> scripts, then it ought not to be adopted.

Don't worry, no shell scripts are in danger (at least for this reason).

We're talking about 1003.2a, the User Portability Extension, here, not
the base 1003.2 standard.  1003.2 does specify traditional post-v7
Bourne behavior for comments in shell scripts.  The question was, does
1003.2a specify the same behavior for interactive use.  It appears
that it does.
--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 27, Number 53

From [e-mail]  Wed Apr  1 21:59:02 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26706; Wed, 1 Apr 92 21:59:02 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28498; Wed, 1 Apr 92 21:59:09 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
References: <[e-mail]>
Date: Wed, 1 Apr 1992 05:29:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David J. MacKenzie)

> What is P1003.2a doing specifying the behaviour of vi-mode command line
> editing in the first place? Is it specifying that "the shell" be ksh?

There's been an ongoing battle during the drafting process between
those who want it to specify a Bourn-like shell and those who want a
Korn-like shell.  The current draft is somewhere in between.
--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 27, Number 54

From [e-mail]  Wed Apr  1 21:59:08 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26724; Wed, 1 Apr 92 21:59:08 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28520; Wed, 1 Apr 92 21:59:14 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on IEEE Standards Board, Dec. 1991
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor


          The IEEE Standards Board

          An Anonymous Friend  of USENIX  reports on the December 3-5,
          1991  meeting in New York, NY:

          [ed. -_- The report writer asked to remain anonymous. Anyone
          wishing to  send comments  to the writer  may do so  through
          me.]

          The IEEE  Standards Board is  the committee responsible  for
          overseeing all standards related activities within the IEEE.
          The  IEEE  produces  standards  for  the  entire  electrical
          engineering spectrum,  not  just the  Computer Society.  The
          Technical  Committee  on  Operating  Systems  --  Standards
          Subcommittee  (TCOS-SS),  is   the  IEEE  Computer   Society
          committee responsible for the POSIX family of standards.

          As usual, the  December 1991 meetings  of the IEEE Standards
          Board produced a  plethora of new  Project Approval Requests
          (PARs) and approved projects, some new rules to apply to the
          standards  process,   and   one  more   new   Organizational
          Representative that can ballot POSIX standards.

          Acknowledgments

          Perhaps the new  rule that most  impacts the IT community is
          one  concerning  the   use  of  acknowledgment  sections  in
          standards.   You've  probably  seen  one of  these  sections
          before;    they're    the     ones    that    thank     your
          company/university/organization/mother  for  providing   the
          means for you  to contribute your thoughts and ideas to that
          lovely thing known  as the standards  process.  It's usually
          found in  the  front or  back  of the  standard  in what  we
          jargon-savvy  folks know  are  informative sections  of  the
          document, so it's not part of the official standard.  (Don't
          confuse it with  the foreword or introduction, which discuss
          the technical and historical development of the standard and
          list the working group and balloting group.)

          The IEEE Standards  Board Procedures Committee (whew! that's
          ProCom for short) felt that the IEEE could be legally liable
          if the  standards mentioned a  company without first  asking
          their permission.  A policy was proposed that said a working
          group could  include  one of these  sections if each  member
          obtained   written   permission  from   the   companies/etc.
          involved,  to  be  kept  on  file  with the  IEEE  Standards
          Department. There are  form letters for  you to follow,  but
          nonetheless it's an extra step you'll have to take.

          Of course, the question comes up as to whether you should be
          doing this work at all.  What if one company says yes and 20
          say no?  Do  you have an  acknowledgments section that  only
          lists a  few  companies?  For  a  family of  standards  like
          POSIX, should some standards have this section and some not?
          As always, things rapidly get complicated.  Because of this,
          the POSIX  technical  editors had  a  lengthy discussion  on
          whether to have  these sections at  all in their  documents.

          Opinion was  wide-ranging and  varied; the interim  decision
          was to go to our individual working groups and ask for their
          opinions.  Based on those discussions, the technical editors
          will decide whether to keep these sections in the future.

          The Curse of Acronyms

          As we  all know, standards-writing  groups have a  seemingly
          inexhaustible ability to  create acronyms.  Indeed,  after a
          while  our  conversations   seem  to  consist   entirely  of
          abbreviations,  and  woe  betide  the  person who  tries  to
          understand our arcane internal code.

          Of course, the Standards Board has to do just that when they
          look  at  our  PARs,  (oops!  that's  Project  Authorization
          Requests.)  They understandably  get frustrated.  Because of
          that, the  New  Standards Committee  (NesCom) has said  that
          they don't  want  to see  incomprehensible  acronyms on  PAR
          submissions in the future.  The NesCom members come from all
          societies of the  IEEE, not just  Computer, and many  power-
          engineering standards  developers  can't begin  to guess  at
          what an acronym  means that you've used since the first time
          you touched a keyboard.

          This means we'll  have to get  used to standards titles that
          are even longer  than they are now!  When filling out a PAR,
          you'll have  to remember  to expand acronyms  appropriately.
          You wouldn't want to have the PAR rejected on these grounds.
          This subject will  be discussed in  more detail at  the next
          NesCom meeting.

          One Man, One Vote

          Questions have arisen  as to whether  or not members such as
          Institutional Representatives and  similar reps in the power
          engineering realm  vote  twice on  a  document, once  as  an
          individual   and    possibly   again   representing    their
          organization.   The  Board  agreed  to  appoint  an  ad  hoc
          committee to look  at the issue  of one man, one vote.  More
          information should be available from forthcoming meetings.

          In other IR  related news, SPARC  is now officially approved
          by the IEEE  Standards Board as  an IR and  has the right to
          vote on all POSIX documents.

          [ed. -_-  The  following lists  are  provided, to allow  the
          reader to appreciate  the full breadth  of control the  IEEE
          Standards Board has as its mandate. These are still just the
          Computer Society related  standards.  The reader should note
          P1279, P1281, and P1282. Andrew Hume regularily warns in his
          ANSI WORM standards reports that the WORM standards may have
          a far broader  impact than people think.  Here, in P1282, we
          even  see  them  ``worming''  their  way into  POSIX.1  (ISO
          9945-1).]

          And here's the  information on Review Committee (RevCom) and
          NesCom Computer Society activity:

          Approved New Computer Society PARs

          P1278   (C/SCC)   Standard   for   Information   Technology-
          Distributed Simulation Applications-Process  and Data Entity
          Interchange Formats

          P1279  (C/SCC)  Standard for  Information  Technology-CD-ROM
          Architectural Profile

          P1281 (C/SCC) Standard for Information Technology-Use of ISO
          9660:  1988 System Use Fields

          P1282   (C/SCC)   Standard   for   Information   Technology-
          Interchange of ISO 9945-1:1990 Filesystems via the ISO 9660:
          1988 File Structure

          P802.1j  (C/TCCC)  Standard  for  Managed  Objects  for  MAC
          Bridges (Supplement of 802.1D)

          P802.1k   (C/TCCC)   LAN/MAN  Management   Information   for
          Monitoring
          and Event Reporting

          P802.2C (C/TCCC) PICS  Proforma for LLC Type 1 Operation and
          LLC Type 2 Operation

          P802.1D (C/TCCC) Technical and Editorial Corrections to Std.
          802.1D

          P802.2f (C/TCCC) Standard for LLC Sublayer Management

          P802.6k (C/CC) Distributed  Queue Dual Bus  Subnet work of a
          Metropolitan Area Network, Supplement for MAC Bridging

          Revised Approved Computer Society PARs

          P1209 (C/SE)  Recommended  Practice for  the Evaluation  and
          Selection of CASE Tools

          P802.1F (C/CC)  Common  Definitions and  Procedures for  802
          Management Information

          P1155   (C/MM)   Standard    for   VMEbus   Extensions   for
          Instrumentation:  VXIbus

          P1175  (C/SCC)  Trial   Use  Standard  Reference  Model  for
          Computing System Tool Interconnections

          P1396 (C/MM) Standard for a Communication Bus (TELECOM Bus):
          Reference Models

          Withdrawn Computer Society PARs

          P1101.5 (C/MM)  Standard  for Mechanical Core  Specification
          for Microcomputers-Desktop Form Factor

          Approved New Computer Society Standards

          610.6  (C/SCC)  Standard   Glossary  of  Computer   Graphics
          Terminology

          1029.1  (SCC20  & C/DA)  Standard  for Waveform  and  Vector
          Exchange (WAVES)

          1175  (C/SCC)  Trial   Use  Standard  Reference   Model  for
          Computing System Tool Interconnections

          P1212  (C/MM) Standard  Control  and Status  Register  (CSR)
          Architecture for Microcomputer Buses

          Withdrawn Computer Society Standards

          IEEE   Std   662-1980,   IEEE  Standards   Terminology   for
          Semiconductor Memory (ANSI)


Volume-Number: Volume 27, Number 55

From [e-mail]  Wed Apr  1 21:59:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26737; Wed, 1 Apr 92 21:59:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28575; Wed, 1 Apr 92 21:59:21 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.2, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:15 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
                Stephen Walli <[e-mail]>, Report Editor


          Report on POSIX.2: Shell and Utilities

          David Rowley  <[e-mail]> reports  on the January  13-17
          meeting in Irvine, CA:

          Summary
          The end is  in sight.  POSIX.2  (Shell and Utilities)  Draft
          11.2 closed its recirculation ballot last October 21.  Draft
          11.3 is due  out any day  now.  A full draft (Draft 12) will
          be recirculated to  the IEEE working  group before the final
          standard is  adopted.   POSIX.2a (UPE)  Draft  8 closed  its
          recirculation  ballot on  January  24.  Both  standards  are
          expected to be  approved as full-use  IEEE standards at  the
          September meeting of the IEEE Standards Board.

          Work on  POSIX.2b continues,  including the contentious  new
          file format for  PAX and extensions to the POSIX.2 utilities
          to handle symbolic links.

          The  first  cut  at test  assertions  for POSIX.2  has  been
          wrapped up, and assertions for POSIX.2a begun.

          Background

          A brief POSIX.2 project description:
          -- POSIX.2 is  the  base standard  dealing  with the  basic
            shell programming language and a set of utilities required
            for the  portability of shell  scripts.  It excludes  most
            features that  might  be considered interactive.   POSIX.2
            also  standardizes  command-line and  function  interfaces
            related  to  certain  POSIX.2  utilities  (e.g.,  popen(),
            regular expressions,  etc.). This  part of POSIX.2,  which
            was  developed  first,  is  sometimes  known  as  ``Dot  2
            Classic.''
          -- POSIX.2a, the  User Portability Extension  or UPE, is  a
            supplement to the base standard. It standardizes commands,
            such as vi,  that might not  appear in shell  scripts, but
            are important  enough  that users must  learn them on  any
            real system.  It  is essentially an  interactive standard,
            and will  eventually  be an optional  chapter to a  future
            draft of  the  base document.   This  approach allows  the
            adoption  of  the  UPE  to  trail  Dot 2  Classic  without
            delaying it.
            Some utilities have  both interactive and  non-interactive
            features.  In such  cases, the UPE defines extensions from
            the   base   POSIX.2    utility.    Features   used   both
            interactively and  in  scripts tend to  be defined in  the
            base standard.
          -- POSIX.2b is  a newly approved  project which will  cover
            extensions and new  requests from other  groups, such as a
            new file format for PAX and extensions for symbolic links.

          Together,  Dot  2  Classic  and the  UPE  will make  up  the
          International  Standards  Organization's   ISO  9945-2--the
          second  volume  of   the  proposed  ISO  three-volume  POSIX
          standard.

          POSIX.2 Status

          Hal Jespersen, Chair  of POSIX.2, is about to send out Draft
          11.3.  This  is  likely the  last ``changes-only'' draft  of
          POSIX.2.

          The POSIX.2/D11.2  recirculation  ballot closed October  21,
          and resolution of ballot objections has completed.

          Balloting of  Draft  11.2 has  been  held open  pending  the
          arrival of  ISO  comments.  All changes  for the next  draft
          (11.3) will be forwarded to ISO through the US TAG.

          It is expected that a final draft 12 of POSIX.2 will be made
          ready in time  for the May  WG15 meeting in New Zealand, and
          should be approved as a Draft International Standard.

          The technical  content  of the  standard  has more  or  less
          stabilized.  Most recent changes relate to clarifications in
          wording.

          POSIX.2a Status

          POSIX.2a  is  also  coming down  the  home stretch,  as  the
          technical content  has  stabilized.  Ballot  resolution  for
          POSIX.2a (UPE) Draft  8 was completed.  The ballot closed on
          January  24.   The   next  draft  will  likely  be  a  quick
          ``changes-only''  recirculation,  labelled  draft  8.1.   It
          should appear any day now.

          The ISO ballot  ends in April.   All comments will be rolled
          into a Draft  9 which will be produced in time to be carried
          to ISO in May for approval as a Draft International Standard
          (DIS).

          Hal Jespersen  expects that both  standards should be  given
          final full-use IEEE approval at the September meeting of the
          IEEE Standards Board.

          Internationalization Inadequacies

          Randall Howard, President  of MKS, put forward a proposal to
          the POSIX.2b  working group  to define a  system API to  the
          internationalization  information  embodied   in  a  POSIX.2
          locale.   Routines  to  access  collation  elements,  detect
          membership within  a character class  and extensions to  the
          strftime() call were  presented.  The group  felt that since
          it was a system API, not a utility, it rightfully belongs in
          POSIX.1.  When the  same presentation was  given to POSIX.1,
          they expressed the  opinion that parts  of the proposal were
          better  suited  to  the  ANSI  or  ISO C  Standard  efforts.
          Unfortunately, they  don't  necessarily want  it since  they
          haven't (yet)  adopted the POSIX.2  definition of a  locale.
          This  all  demonstrates   that  the  POSIX   process  cannot
          effectively deal  with  issues that cut  across a number  of
          working  groups  and/or   standards.   Perhaps  the  Systems
          Interface Coordination  Committee  (SICC) that has  recently
          been formed  within  POSIX can  help  address some of  these
          issues.

          Comments on ISO 10646

          The ISO working  group that is responsible for the ISO 10646
          character  set  standard  (which  now includes  the  Unicode
          work,) has asked the POSIX.2 working group for their opinion
          on their current proposal.

          The working  group  expressed much concern  over the use  of
          null  octets  within   the  valid  character  codes.   Since
          computer languages  such  as ``C''  make use  of nulls as  a
          string termination marker, a lot of existing code would have
          to be heavily modified in order to support the new standard.
          The working group  was against the proposal for this reason.
          Apparently  the  ISO/ANSI  C  working  group  has  expressed
          similar concerns.

          Symbolic Links

          Dawn Burnett from  USL submitted a proposal on extending the
          POSIX.2 and  POSIX.2a utilities  to support symbolic  links,
          based on  the  System V  implementation.  The problems  that
          arise from  symbolic  linked directories  were discussed  at
          length.  There is nothing more irritating than changing to a
          directory, printing  the current  working directory only  to
          find that  you  have been magically  warped to a  completely
          different spot in  the file system.   A proposal to maintain
          both physical (``Where  am I'') and virtual (``How did I get
          here'') paths was  offered.  The text will find its way into
          the next draft of POSIX.2b for further discussion.

          Test Methods

          Real  progress  was   made  completing  the  remaining  test
          assertions for POSIX.2,  and beginning the  POSIX.2a work. A
          style guide  for  writing consistent  assertions has yet  to
          appear, but the  group seems to have found its stride and is
          working well.

          Test assertions for the interactive utilities have yet to be
          tackled, but it is expected that it will not be as difficult
          as first anticipated.   The assertions for ``vi'', ``talk'',
          etc will describe (in precise English) what action must take
          place  upon  the  stated  input.   The process  whereby  the
          results are  verified  will be  left  up to  the test  suite
          implementor.

          New PAX Archive Format

          Work continues on  the new PAX  archive format.  A consensus
          is  (slowly)  starting  to  brew.  The  issue  of  supported
          filename code sets  is a thorny  one, especially since POSIX
          has not addressed any code set issues in a general way (such
          as adopting the X/Open iconv utility and API).

          The problems stem  from wanting to use the format to address
          both universal  archive  transportability as  well as  local
          file system  backup  and restore.   One  concentrating on  a
          standard common ground, the other wanting the flexibility of
          representing the full local filename character set.  This is
          the most  contentious  area of  the  format, and there  will
          likely be much wailing and gnashing of teeth before the dust
          settles.

          If you have  any interest in  this area, the  group would be
          pleased to hear from you.


Volume-Number: Volume 27, Number 56

From [e-mail]  Wed Apr  1 21:59:24 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26745; Wed, 1 Apr 92 21:59:24 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28627; Wed, 1 Apr 92 21:59:30 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.6, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:16 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor


          POSIX.6: Security Extensions

          Charisse  Castagnoli  <[e-mail]>  reports  on  the
          January 13-17, 1992 meeting in Irvine, CA:

          Summary of the POSIX meeting in Irvine

          This was the  first meeting of  the POSIX.6 group  since the
          ballot closed  on  January 6,  1992.   Of the  232  official
          ballot members, 181  members responded.  The response equals
          78 %of  the  ballot pool.   (A  minimum of  75% response  is
          required by IEEE for a ballot to be considered valid.)

          The 181 returned ballots were divided as follows:

                      Affirmative  Negative     Abstain
                          69          61          51
                          53%        47%     <don't count>

          In  order  for  a  ballot  to  pass,  there  must be  a  75%
          affirmative ballot.  One  would think this  means 75% of the
          responses must  be  affirmative, but this  is not the  case.
          Only 75% of the non-abstaining votes need to be affirmative.
          Taken to  an  extreme, this  means  that regardless  of  the
          ballot pool  size,  if 3  people  vote affirmative, 1  votes
          negative and the  rest abstain, the  initiative passes.  The
          moral of the story is:  abstain only as a last resort, there
          may be deleterious side effects.

          The POSIX.6 committee is now divided into 3 groups:
          -- test assertions,
          -- new projects,
          -- ballot technical reviewers.

          The  test  assertions   group,  led  by   David  Rogers,  is
          developing the companion  document of test assertions.  This
          is required to actually complete the ballot process.

          The  new   projects   group  is   working  on  new   Project
          Authorization Requests (PARs).  Three PARs were presented:
          -- one PAR for Identification and Authentication,
          -- one for data interchange,
          -- and one for terminal I/O.

          In addition,  PARs  were prepared  for the existing  POSIX.6
          functions.  The current  PAR for the  existing functionality
          will  eventually  be  transformed  into  POSIX.6a  (Security
          Extensions  to  System  Interfaces) and  POSIX.6b  (Security
          Extensions to  System Utilities and  Shell).  [ed. -_-  PARs
          are essentially  administrative  project control  documents,
          but  are  becoming  administrative  nightmares in  the  IEEE
          standards development process.]

          The  ballot  resolution  group  began reviewing  the  ballot
          objections.   A  preliminary  analysis  indicated  that  one
          common objection was  lack of consistency within the ballot.
          Requests  for  consistency   in  function  naming,   calling
          parameters,  data  types  and  return codes  were  frequent.
          After careful reflection, the ballot resolution group agreed
          this was a reasonable request and began to work out a set of
          guidelines to ensure consistency throughout the draft.

          Highlights  of  the   ballot  resolution  group  discussions
          include:
          -- Should ``set''  and ``get'' be  used for function  names
            instead of ``read'' and ``write?''
          -- Should data  types be contiguous  in memory?  (That  is,
            can a data object be copied with a bcopy().)
          -- Should functions manage  data storage and  allocation or
            should the programmer manage them?

          After arduous  negotiations,  the group  developed a set  of
          guidelines, that resolved  many issues that have plagued the
          drafts for years.  The ballot resolution group will now join
          the State  Department to support  peace negotiations in  the
          Middle-East.

          The  ballot  resolution   group  tested  the  guidelines  by
          applying them to each of the primary functions in the draft.
          These functional  areas  are privilege mechanism,  mandatory
          access control (including  information labeling), and access
          control  lists.   The  auditing  functions were  granted  an
          exemption  from  this  exercise,  because  they  were  being
          reviewed  in  light  of the  new  data type  guidelines  and
          substantial interface modifications were expected.

          Chris  Hughes  presented   some  options  for  new  auditing
          interfaces.  The existing  interfaces, in addition  to being
          inconsistent,  lack  good   support  for  application  level
          auditing.   Additional  work   is  needed  on  the  auditing
          functions, and will be presented at the next POSIX meeting.

          At the end of the meeting, we all agreed to try and complete
          the interface  changes necessary to  bring each function  in
          line with the  new guidelines.  We also agreed to resolve as
          many ballot objections as possible before the April meeting.


Volume-Number: Volume 27, Number 57

From [e-mail]  Wed Apr  1 21:59:31 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26759; Wed, 1 Apr 92 21:59:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28652; Wed, 1 Apr 92 21:59:36 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.0, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:14 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor


          POSIX.0: The Guide to Open Systems

          Kevin  Lewis  <[e-mail]>   reports  on  the
          January 13-17, 1992 meeting in Irvine, CA:

          The  POSIX.0 working  group  adjourned the  October  meeting
          wondering what the mock ballot would yield.  This ponderance
          was focused not  only on the size of the return, but also on
          whether there were  any hidden or significant issues lurking
          in the darkness.

          Twenty six mock  ballot responses were received: 13 users, 9
          producers,  and  4   general  interest  participants.   This
          reflects  a   healthy   balance.   In   total,  there   were
          approximately 760 objections/comments.  Some ballots covered
          specific sections, while others addressed the entire guide.
          It appears that  the issue of ``public specifications'' that
          has been  lurking  around in other  venues has arisen  here.
          For those of  you not familiar  with this, I  can not do  it
          justice here.  Suffice  it to say  that it involves  the use
          within public  procurements of  specifications that are  not
          currently in  the  formal standards  process but which  have
          widespread industry use and acceptance.

          POSIX.0 feels that  such specifications are acceptable under
          specific conditions  which include consensus,  availability,
          lack of encumbrances,  and proper documentation.   (There is
          much, much more  to this, so get a copy of the guide or call
          someone in POSIX.0 if you are interested or concerned.)

          The decision  was  made in  January to  move forward on  the
          formal ballot.  POSIX.0  has notified the  IEEE and a letter
          forming the formal  ballot group will  go out in  the March-
          April time frame.  The goal is to begin the formal ballot in
          July 92.  In  parallel, POSIX.0 will be submitting the guide
          to the international  standards community in order to obtain
          review and comment  and to prepare  the way for it as an ISO
          Technical Report.


Volume-Number: Volume 27, Number 58

From [e-mail]  Wed Apr  1 22:03:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26879; Wed, 1 Apr 92 22:03:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29480; Wed, 1 Apr 92 22:03:57 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.3, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:16 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor


          Report on POSIX.3: Test Methods and Conformance

          Andrew  Twigger  <[e-mail]>  reports  on  the  January
          13-17, 1992 meeting in Irvine, CA:

          SCCT Matters

          The Steering  Committee  on Conformance  Testing (SCCT)  met
          three times during  the week and  discussed a broad range of
          testing  related issues.  The  major issues  centred  around
          fitting  the  test  methods  into  the  document  structure,
          dealing with options in ``base'' standards, and test methods
          for profiles.

          The higher level  of document structure  seems to have  been
          resolved by  introducing  a parallel  set of documents  (and
          therefore project requests,  or PARs) to the base standards.
          The test methods  documents will be  numbered by adding 1000
          to  the   base  standard   number,  i.e.  POSIX.6   Security
          Extensions (P1003.6)  will have test  methods in a  document
          numbered  P2003.6.   The   IEEE  would   then  resolve   any
          accompanying publication issues.

          The more granular issue of how to write assertions which can
          be easily  merged  along with  the  base standard  was  also
          briefly discussed, but not yet concluded. The integration of
          base standards (POSIX.1,  POSIX.4, POSIX.6, etc.)  is one of
          the  major  problems  facing TCOS  at  the moment,  but  the
          solution seems as far away as ever. (The Technical Committee
          on Operating Systems -- Standards Subcommittee, TCOS-SS, is
          the  IEEE  Computer Society  TC  responsible for  the  POSIX
          standards.)

          From the  test  methods perspective, integrating  assertions
          for  a   pervasive  interface   like  open()  introduces   a
          considerable problem in  defining which assertions relate to
          which base standard options. While solutions can be produced
          easily, these are generally inelegant.

          The options issue,  which was left  over from the Parsippany
          meeting  was  re-addressed  with  some  further  input  from
          POSIX.1. The  problem  may not be  as serious as  previously
          thought and  many  of the  issue can  be resolved with  some
          minor  changes  to  POSIX.3.1  (POSIX.1 Test  Methods).  The
          remaining   ones  can   be   resolved  by   introducing   an
          announcement  mechanism,  which  most  test suites  have  to
          provide,  allowing   the   test  suite   to  determine   the
          implementation's option setting.

          The SCCT reviewed the meaning of profile conformance and the
          use of conformance  statements in profiles. They agreed that
          profile conformance statements should refer back to those in
          the base standards  and should be  validated by reference to
          the test  methods for the  base standards, where  available,
          plus the specific test methods for the ``mortar'' defined in
          the profile.  (The  Profiles Steering Committee  is reaching
          agreement on  the rules for  subsetting base standards,  and
          how additional behaviour may be thought of as the ``mortar''
          binding the standards together.)

          Software Testing Environment BOF

          On Monday  evening BSI  (the British Standards  Institution)
          and  Mindcraft  called  a  Birds-of-a-Feather  gathering  to
          explain  Software  Testing  International and  the  Software
          Testing Environment  (STE).  Software Testing  International
          would be a  non-profit organisation set up to administer the
          development of  test suites for  POSIX and other  standards.
          Most of the  attendees seemed reticent  in there approval of
          the  scheme,  particularly   when  it  became  evident  that
          Mindcraft   would  be   the   sole  test   suite   authoring
          organisation with  a  seat on the  Board. Comments from  the
          presenters that ``POSIX  testing is just  starting to become
          serious''  were  also  not  particularly well  received.  It
          seemed clear  that  both structural  and perceptual  changes
          would be necessary  before the proposed scheme could make an
          impact in the POSIX testing arena.

          The actual STE  introduces an additional API layer on top of
          the  current  Test   Environment  Toolkit  (TET),  a  freely
          available testing  harness created  jointly by X/Open,  Unix
          International, and  the  Open Software  Foundation.  Initial
          impressions were that  the main purpose  of this layer is to
          allow Mindcraft's CTS  based test suites  to execute in  the
          TET environment.  (NIST is currently  supporting the TET  as
          their testing methodology of choice.)

          Mindcraft  promised  to  make the  specifications  available
          shortly and to  be providing an implementation at the end of
          quarter two.  The  testing community  will  spend some  time
          reviewing  the   value   of  these   extensions,  but   with
          significant aspects like  distributed testing omitted it may
          not capture many peoples imagination.
          POSIX.3

          The POSIX.3 working group continued in there relentless task
          of writing and  reviewing assertions for  the POSIX.2 (Shell
          and Utilities) standard. The latest draft (POSIX.3.2/D7) has
          been circulated for  review and comment,  though no comments
          have yet been received.  At the end of the Irvine meeting it
          was expected  that  there would be  no significant parts  of
          POSIX.2 that  were unaddressed by  test methods, except  its
          internationalisation aspects.   The working group  commenced
          the specification of test methods for POSIX.2a (UPE) towards
          the end of the meeting.

          Other working groups  were also developing  test methods for
          their  standards  with progress  being  made by  (at  least)
          POSIX.6, POSIX.8,  POSIX.12,  1224 and  POSIX.17 as well  as
          some of  the  profile groups. In  general these groups  were
          developing a  reasonable  understanding of  the task  facing
          them, and  in  some cases  good  quality test  methods  have
          already been produced.

          The  question  of  language  independent  test  methods  was
          discussed in  the  POSIX.1 forum,  though other groups  (for
          example 1224)  have  also made  progress  in this area.  The
          outcome of  the  POSIX.1 discussion  was  an estimate  by  a
          prospective contractor to  undertake 2,000 or  more hours of
          work to  produce  LIS test methods  for POSIX.1. This  looks
          like  an  exceedingly  high estimate  and  I would  be  very
          surprised if TCOS followed it up!


Volume-Number: Volume 27, Number 59

From [e-mail]  Wed Apr  1 22:03:58 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26894; Wed, 1 Apr 92 22:03:58 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29500; Wed, 1 Apr 92 22:04:04 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.14, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor


          POSIX.14: Multiprocessor Profile

          Rick Greer <[e-mail]>  reports on the January 13-17,
          1992 meeting in Irvine, CA:

          The multiprocessor working group plans to submit their draft
          profile to a mock ballot after the April 1992 meeting.  Much
          of  the  January  meeting  was  spent dealing  with  various
          trivialities  in  the  draft  in  anticipation of  the  mock
          ballot.  We  did,  however, encounter  one major issue  that
          could  prevent  the  draft  profile  from  ever  becoming  a
          standard.  It  seems  that a draft  profile cannot become  a
          ``POSIX Standard Profile''  if it references documents which
          are  not  themselves   official  standards  endorsed   by  a
          ``recognized  accrediting   body''.    The  POSIX.14   draft
          references  both  the   POSIX.4  (Real-time)  and   POSIX.4a
          (Threads) drafts,  as  well as some  ongoing ANSI X3H5  work
          defining parallel language  facilities.  It cannot  become a
          standard profile until  all of these  make their way through
          the appropriate standardization mill.

          The POSIX.14  profile  is fairly  simple,  and likely to  be
          ready for  balloting long  before its antecedent  documents.
          This forces the  POSIX.14 working group into one of a number
          of possible holding actions:

          1. Hold up balloting  the POSIX.14 profile  until all of the
             referenced documents become  standards.  This will  leave
             the working group  with very little to do, except perhaps
             to  work  with  the  other groups  to  try and  speed  up
             acceptance of  their  work.  Since  most of the  POSIX.14
             working group are  refugees of the POSIX.4a threads wars,
             there is very  little enthusiasm within POSIX.14 for this
             approach.

          2. Go  ahead  and ballot  the  POSIX.14 profile,  but  don't
             submit it to  the IEEE Standards Board for approval until
             the referenced  documents  become standards.  This  gives
             the working  group  something to  do  over the  next  few
             months (i.e,  work on ballot  resolutions).  In the  long
             run it will  only delay the inevitable:  We are likely to
             run  out  of  ballot  objections  long before  the  other
             documents become standards.

          3. There  are  a   number  of  ``missing  interfaces''  that
             POSIX.14 would like  to see added  to POSIX.1 and POSIX.2
             but, being a  profile group, is  unable to specify.  What
             we can  do  is to  recommend  to other  groups that  they
             incorporate these interfaces  into subsequent versions of
             their   documents   to  better   support   multiprocessor
             operation.  The general  feeling within POSIX.14  is that
             if we do  a thorough job of presenting well defined, well
             rationalized,  multi-  processor  interfaces,  the  other
             working groups should  pick them up  with little argument
             (ha!).  While waiting  for the draft documents referenced
             by the POSIX.14 profile to become standards, the POSIX.14
             working group could  devote some effort to defining these
             missing interfaces.

          We pretty much  decided to go  with holding action  number 3
          (primarily because  it's more  fun than items  1 or 2),  but
          this course of  action presents problems  of its own.  If we
          wish to include  the missing interfaces into the profile, we
          will have to wait for them to become officially adopted into
          POSIX.1 and POSIX.2.   This would, of  course, put us  right
          back where we  started:  Waiting for referenced documents to
          become standards before the profile itself can be finished.

          One  way out  of  this dilemma  is  to include  the  missing
          interfaces in an  appendix to the  profile itself. Once  the
          interfaces have become  recognized standards, we can include
          them  in the  normative  text in  a  later revision  of  the
          profile.


Volume-Number: Volume 27, Number 60

From [e-mail]  Wed Apr  1 22:04:03 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26908; Wed, 1 Apr 92 22:04:03 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29555; Wed, 1 Apr 92 22:04:10 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX Dist. Security Group, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:19 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
                Stephen Walli <[e-mail]>, Report Editor


          Report on the POSIX Study Group on Distributed Security

          Laura Micks <uunet!aixsm!micks>  reports on the  January 15,
          1992 meeting in Irvine, CA:

          A study group has formed to investigate the feasibility of a
          project request (PAR) for Distributed Security.

          One of the  major topics raised  at the Distributed Services
          Steering Committee (DSSC)  was the problem  of Security in a
          Distributed environment.  This issue is not addressed by the
          Security working  group  (POSIX.6), nor  any of the  working
          groups under the DSSC.

          A  meeting  was  scheduled  for  all interested  parties  to
          discuss future  directions  in this  area. Approximately  20
          people attended and  the application was made to be approved
          as a Study  Group.  If approved, a Study Group can be funded
          (from  a  logistics  point  of  view)  to meet  for  several
          meetings without an  official PAR in place.  The group plans
          to meet for an entire week next meeting cycle.

          Most of  the  attendees were from  the Security and  Systems
          Management  groups.   Several  people attended  for  general
          interest.  It took the group quite some time to get rolling.
          There seemed  to be 2  camps:  one that  wanted to define  a
          conceptual model, identify  services required, etc., and the
          other that wanted  to pin down the existing implementations,
          choose one and tweek it where necessary.

          A PAR was  actually drafted in October 1991 by Data Logic on
          behalf  of  Petr   Janecek  of  X/Open.   The  PAR  was  not
          officially  submitted   to   the  POSIX  Sponsor   Executive
          Committee, probably  due  to potential  lack of support  and
          sponsorship within the  POSIX community.  The  draft of this
          PAR was copied and distributed to the study group.

          Known existing  projects  and organizations working  similar
          efforts were identified.   The known models  identified were
          as follows:

          -- Open   Software   Foundation's   Distributed   Computing
            Environment (DCE)
          -- NIS (Sun)
          -- ECMA TC46 Technical Committee on Security Framework
          -- ISO  7498-2  Security  Addendum  covering  Architectural
            Framework/Security Svcs
          -- The Andrew File System (AFS)
          -- Project Athena
          -- GSSAPI - A generic security API from DEC
          -- Project MAXSIX
          -- DNSIX - (Mitre)
          -- Netware
          -- GASSP  (Generally Accepted Security System Principles)
          -- U.S. Government OSI Profile (GOSIP)

          We  decided  to  further  the  study  by arranging  as  many
          presentations as feasible  from the list above for the April
          meeting.   The   meeting   agenda  will   be  to  hear   the
          architectural  presentations  on  security  models,  and  to
          determine  selection  requirements  for base  documents.   A
          thorough evaluation will be made at the July meeting.

          It is premature  to assess the viability of this study group
          becoming an actual POSIX committee.  The initial meeting was
          somewhat disorganized but  in all fairness, there was little
          or no  advance  notice of  this  group's meeting, hence  the
          attendees were  unprepared.   Given the  sensitivity of  the
          subject and  the obvious differences  of opinions raised  at
          the January  meeting,  I don't expect  that the exercise  of
          selecting a particular  model to be  used as a base document
          will be trivial.

          The next meeting  will be held  in conjunction with the next
          IEEE POSIX working group meetings:
          April 6-10, 1992,
          The Doubletree Dallas at Lincoln Centre,
          Dallas, TX.


Volume-Number: Volume 27, Number 61

From [e-mail]  Wed Apr  1 22:04:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26919; Wed, 1 Apr 92 22:04:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29576; Wed, 1 Apr 92 22:04:16 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.17, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:18 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor

          Report on POSIX.17 - Directory Services API

          Mark Hazzard <[e-mail]>  reports on the January
          13-17, 1992 meeting in Irvine, California:

          Summary

          Once again, the  POSIX.17 group made  solid progress between
          meetings, completing  all  major homework  assignments.  The
          week  in  Irvine  was a  busy  one.  The  Project  Managment
          Committee (PMC) audited  POSIX.17 and gave the group a clean
          bill of health.   We also met  with POSIX.12 furthering  our
          discussion on a  simplified API to  the directory.  Our Mock
          ballot input on the networking section of the Guide, POSIX.0
          Draft 14, were  reviewed with POSIX.0, with the promise that
          they will  be  reflected in  the  next draft.  We  completed
          processing input from  our Mock Ballot of POSIX.17 Draft 2.0
          and began  drafting  responses to  our  reviewers.  We  also
          identified work items and continued planning for an official
          IEEE ballot which begins April 7, 1992.

          Introduction

          The POSIX.17  group  is generating a  user to directory  API
          (e.g. an  API  to an  X.500 Directory  User Agent).  We  are
          using  the  joint   XAPIA  --  X/Open   Directory  Services
          specification (XDS) as  a basis for  work. XDS is  an object
          oriented  interface  and   requires  a  companion  document,
          X/Open's Object  Management  specification (XOM) for  object
          management.

          XOM   is   a    stand-alone   specification   with   general
          applicability beyond the API to directory services.  It will
          also be used by IEEE P1224.1 (X.400 API), and possibly other
          POSIX groups, and  is being standardized  by P1224.  Draft 4
          of P1224 has already entered IEEE ballot.

          POSIX.17 is one  of five "networking"  groups that currently
          make up  POSIX  Distributed Services  and as such,  POSIX.17
          comes under the purview of the Distributed Services Steering
          Committee (DSSC).

          Status

          The group chair  was unable to attend the meeting in Irvine,
          CA, so yours  truely once again assumed the duties of chair.
          There has  been  a low  grumble  about the  ever  increasing
          overhead associated with  TCOS/POSIX working groups, and now
          I know  why.  A Project  Management  Committee audit  Sunday
          morning, 2  Sponsor  Executive Committee  (SEC) meetings,  2
          Systems Interface Co-ordination Committee (SICC) meetings, 2
          Distributed Systems  Steering  Committee (DSSC) meetings,  2
          Distributed Systems (DS)  Plenaries, a Logistics  meeting, a
          Distributed Security  study and  (I almost forgot)  POSIX.17
          working  group  meetings  made  for  a  noticeable  lack  of
          ``spare'' time.

          Commitment within the  group remains strong,  with all other
          core  members  attending,  and completing  their  "homework"
          assignments.

          The TCOS Project  Management Committee held  the first audit
          of  POSIX.17  on   Sunday  morning.   The   PMC  recommended
          continued sponsorship of  the work, splitting  the work into
          two projects, increasing  the size of  the working group for
          ballot resolution and bringing our Issues Log current.

          During the week, the group completed processing the comments
          received from  our  Mock ballot. We  began to draft  written
          responses which will  be sent to all who took time to review
          the draft  and provide us  with comments and/or  objections.
          Several of the  comments/objections resulted in improvements
          to the specification  and will be incorporated into the next
          draft (3.0).  This  will be the  draft that goes directly to
          IEEE ballot April 7th.

          The  Technical  Editor  completed the  Language  Independent
          Specification (LIS) and  a first cut  at test assertions  as
          well.  (X/Open followed  through with their  promise to fund
          our technical editor  to write the  assertions for POSIX.17.
          This made sense  in that X/Open needs to have assertions for
          XDS.) The test assertions were reviewed by a consultant from
          POSIX.3 who had some problems with the way things were done.
          A lively  debate ensued, but  in the end,  we caved in,  and
          will incorporate the  ``suggestions.''  It is estimated that
          90% of our  assertions will require change.  Hopefully, this
          can be automated.

          Once  again,  we  met  with POSIX.12  (Protocol  Independent
          Interfaces)   in   joint   session   and   discussed   their
          requirements on directory services. The POSIX.12 group wants
          a simplified interface  to directory services  for the users
          of their Detailed  Network Interface (read sockets/XTI).  We
          also discussed what  objects POSIX.12 will need to be stored
          by the directory  and how those objects will get documented.
          Given our need  to freeze our  draft for ballot and the lack
          of definition for  both new objects and interface functions,
          we explored possible avenues for proceeding with the work.

          We met in  small group to continue the discussion.  POSIX.17
          participants left the  meeting with a  greater understanding
          of the  issues,  but no  closer  to a  solution.   We had  a
          debriefing session afterwards and decided to produce a white
          paper documenting  agreements, assumptions, issues,  options
          and proposed actions.  This will be used to focus discussion
          at the next small group meeting in April.

          POSIX.17  and   P1224   met  again   in  joint  session   to
          review/revise test assertions  for P1224.  Draft  4 of P1224
          has already entered  ballot and we  agreed to assist them in
          ballot resolution as  time permits.  Test assertions will be
          balloted in  a  recirculation.  Since  P1224 is a  normative
          reference for  POSIX.17, a stable  version is essential  for
          our ballot.

          We sent a representative to POSIX.0's Architecture Framework
          BOF where the  the results of  their recent Mock Ballot were
          discussed.  POSIX.17  had  submitted comments/objections  to
          the  POSIX.0  Mock   Ballot  (Draft  14),  focusing  on  the
          ``networking'' section.  We  were told that all our comments
          and objections  were  accepted and will  be included in  the
          next draft.  The  POSIX.0 model defined  in the Mock  Ballot
          draft seemed to recognize the need for APIs aimed at systems
          integrators as well as end users.

          POSIX.17 shares a  problem with P1224 and P1224.1.  It seems
          that the objects  defined in the  base documents (XDS,  XOM,
          X.400 API) reserved  object ids (OIDs)  in a vendor's  (DEC)
          registered ISO  name  space.  This  might  be ok for  vendor
          consortia, but  it  won't cut  it  for a  de jure  standard.
          Because this  issue  touches more than  one group, the  DSSC
          discussed it and  agreed to produce  a recommendation on how
          to proceed by next meeting.

          In Closing ...

          Again, there  are quite a  few homework assignments  between
          meetings.  (I think  there's a trend  here).  Given this  is
          our  last  quarter   before  ballot,  we  need  to  complete
          formation of  the  ballot group,  fix  the test  assertions,
          finalize Draft 3,  and respond formally  to our Mock  Ballot
          reviewers.  We've also  been actioned by the DSSC and PMC to
          split our current  Project Authorization Request  (PAR) into
          two new PARs,  one which addresses only the API to directory
          services and the  other which addresses the POSIX name space
          issue.

          The group will  reconvene April 6-10, 1992 at the IEEE POSIX
          meeting in the Dallas.


Volume-Number: Volume 27, Number 62

From [e-mail]  Wed Apr  1 22:04:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26940; Wed, 1 Apr 92 22:04:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29598; Wed, 1 Apr 92 22:04:23 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Report on POSIX.17, Jan. 1992
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:35:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

                      USENIX Standards Watchdog Committee
              Stephen R. Walli <[e-mail]>, Report Editor

          Report on POSIX.17 - Directory Services API

          Mark Hazzard <[e-mail]>  reports on the January
          13-17, 1992 meeting in Irvine, California:

          Summary

          Once again, the  POSIX.17 group made  solid progress between
          meetings, completing  all  major homework  assignments.  The
          week  in  Irvine  was a  busy  one.  The  Project  Managment
          Committee (PMC) audited  POSIX.17 and gave the group a clean
          bill of health.   We also met  with POSIX.12 furthering  our
          discussion on a  simplified API to  the directory.  Our Mock
          ballot input on the networking section of the Guide, POSIX.0
          Draft 14, were  reviewed with POSIX.0, with the promise that
          they will  be  reflected in  the  next draft.  We  completed
          processing input from  our Mock Ballot of POSIX.17 Draft 2.0
          and began  drafting  responses to  our  reviewers.  We  also
          identified work items and continued planning for an official
          IEEE ballot which begins April 7, 1992.

          Introduction

          The POSIX.17  group  is generating a  user to directory  API
          (e.g. an  API  to an  X.500 Directory  User Agent).  We  are
          using  the  joint   XAPIA  --  X/Open   Directory  Services
          specification (XDS) as  a basis for  work. XDS is  an object
          oriented  interface  and   requires  a  companion  document,
          X/Open's Object  Management  specification (XOM) for  object
          management.

          XOM   is   a    stand-alone   specification   with   general
          applicability beyond the API to directory services.  It will
          also be used by IEEE P1224.1 (X.400 API), and possibly other
          POSIX groups, and  is being standardized  by P1224.  Draft 4
          of P1224 has already entered IEEE ballot.

          POSIX.17 is one  of five "networking"  groups that currently
          make up  POSIX  Distributed Services  and as such,  POSIX.17
          comes under the purview of the Distributed Services Steering
          Committee (DSSC).

          Status

          The group chair  was unable to attend the meeting in Irvine,
          CA, so yours  truely once again assumed the duties of chair.
          There has  been  a low  grumble  about the  ever  increasing
          overhead associated with  TCOS/POSIX working groups, and now
          I know  why.  A Project  Management  Committee audit  Sunday
          morning, 2  Sponsor  Executive Committee  (SEC) meetings,  2
          Systems Interface Co-ordination Committee (SICC) meetings, 2
          Distributed Systems  Steering  Committee (DSSC) meetings,  2
          Distributed Systems (DS)  Plenaries, a Logistics  meeting, a
          Distributed Security  study and  (I almost forgot)  POSIX.17
          working  group  meetings  made  for  a  noticeable  lack  of
          ``spare'' time.

          Commitment within the  group remains strong,  with all other
          core  members  attending,  and completing  their  "homework"
          assignments.

          The TCOS Project  Management Committee held  the first audit
          of  POSIX.17  on   Sunday  morning.   The   PMC  recommended
          continued sponsorship of  the work, splitting  the work into
          two projects, increasing  the size of  the working group for
          ballot resolution and bringing our Issues Log current.

          During the week, the group completed processing the comments
          received from  our  Mock ballot. We  began to draft  written
          responses which will  be sent to all who took time to review
          the draft  and provide us  with comments and/or  objections.
          Several of the  comments/objections resulted in improvements
          to the specification  and will be incorporated into the next
          draft (3.0).  This  will be the  draft that goes directly to
          IEEE ballot April 7th.

          The  Technical  Editor  completed the  Language  Independent
          Specification (LIS) and  a first cut  at test assertions  as
          well.  (X/Open followed  through with their  promise to fund
          our technical editor  to write the  assertions for POSIX.17.
          This made sense  in that X/Open needs to have assertions for
          XDS.) The test assertions were reviewed by a consultant from
          POSIX.3 who had some problems with the way things were done.
          A lively  debate ensued, but  in the end,  we caved in,  and
          will incorporate the  ``suggestions.''  It is estimated that
          90% of our  assertions will require change.  Hopefully, this
          can be automated.

          Once  again,  we  met  with POSIX.12  (Protocol  Independent
          Interfaces)   in   joint   session   and   discussed   their
          requirements on directory services. The POSIX.12 group wants
          a simplified interface  to directory services  for the users
          of their Detailed  Network Interface (read sockets/XTI).  We
          also discussed what  objects POSIX.12 will need to be stored
          by the directory  and how those objects will get documented.
          Given our need  to freeze our  draft for ballot and the lack
          of definition for  both new objects and interface functions,
          we explored possible avenues for proceeding with the work.

          We met in  small group to continue the discussion.  POSIX.17
          participants left the  meeting with a  greater understanding
          of the  issues,  but no  closer  to a  solution.   We had  a
          debriefing session afterwards and decided to produce a white
          paper documenting  agreements, assumptions, issues,  options
          and proposed actions.  This will be used to focus discussion
          at the next small group meeting in April.

          POSIX.17  and   P1224   met  again   in  joint  session   to
          review/revise test assertions  for P1224.  Draft  4 of P1224
          has already entered  ballot and we  agreed to assist them in
          ballot resolution as  time permits.  Test assertions will be
          balloted in  a  recirculation.  Since  P1224 is a  normative
          reference for  POSIX.17, a stable  version is essential  for
          our ballot.

          We sent a representative to POSIX.0's Architecture Framework
          BOF where the  the results of  their recent Mock Ballot were
          discussed.  POSIX.17  had  submitted comments/objections  to
          the  POSIX.0  Mock   Ballot  (Draft  14),  focusing  on  the
          ``networking'' section.  We  were told that all our comments
          and objections  were  accepted and will  be included in  the
          next draft.  The  POSIX.0 model defined  in the Mock  Ballot
          draft seemed to recognize the need for APIs aimed at systems
          integrators as well as end users.

          POSIX.17 shares a  problem with P1224 and P1224.1.  It seems
          that the objects  defined in the  base documents (XDS,  XOM,
          X.400 API) reserved  object ids (OIDs)  in a vendor's  (DEC)
          registered ISO  name  space.  This  might  be ok for  vendor
          consortia, but  it  won't cut  it  for a  de jure  standard.
          Because this  issue  touches more than  one group, the  DSSC
          discussed it and  agreed to produce  a recommendation on how
          to proceed by next meeting.

          In Closing ...

          Again, there  are quite a  few homework assignments  between
          meetings.  (I think  there's a trend  here).  Given this  is
          our  last  quarter   before  ballot,  we  need  to  complete
          formation of  the  ballot group,  fix  the test  assertions,
          finalize Draft 3,  and respond formally  to our Mock  Ballot
          reviewers.  We've also  been actioned by the DSSC and PMC to
          split our current  Project Authorization Request  (PAR) into
          two new PARs,  one which addresses only the API to directory
          services and the  other which addresses the POSIX name space
          issue.

          The group will  reconvene April 6-10, 1992 at the IEEE POSIX
          meeting in the Dallas.



Volume-Number: Volume 27, Number 63

From [e-mail]  Wed Apr  1 22:04:21 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26950; Wed, 1 Apr 92 22:04:21 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29616; Wed, 1 Apr 92 22:04:29 -0500
Newsgroups: comp.std.unix
From: Hans Mulder <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: University of Nijmegen, The Netherlands
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 1 Apr 1992 11:09:11 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Hans Mulder)

In <[e-mail]> [e-mail] (Doug Gwyn) writes:
>In article <[e-mail]> [e-mail] (David J. MacKenzie) writes:
>>The only explicit mention of `#' for the shell in p1003.2a is in the
>>description of the Vi editing mode.  It's a command to comment-out the
>>current line (excerpted below).  ...

>That's disgusting!
>If 1003.2 is going to break zillions of existing carefuly-written shell
>scripts, then it ought not to be adopted.

You're confusing 1003.2 with 1003.2a.  1003.2 mentions that `#' is the
comment character in scripts and people want 1003.2a to say that it
also works interactively.  That goes without saying for people who are
used to sane shells, but many netters are used to the C shell, which
gets this sort of detail wrong.  Apparently, at least one vendor has
seen fit to duplicate this bug in an otherwise Bourne compatible shell.

--
Hans Mulder        [e-mail]


Volume-Number: Volume 27, Number 64

From [e-mail]  Wed Apr  1 22:04:26 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26959; Wed, 1 Apr 92 22:04:26 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29633; Wed, 1 Apr 92 22:04:34 -0500
Newsgroups: comp.std.unix
From: Tom Glinos <[e-mail]>
Subject: Is POSIX a waste?
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Organization: University of Toronto, Dept. of Statistics
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 1 Apr 1992 16:09:53 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Tom Glinos)

At the risk of being flamed back into the stone age I'll offer
the opinion that the whole POSIX exercise has been a waste, for
the following reasons.

[1] It's never been clear to me what the original POSIX proposals were
supposed to define and accomplish. (What is the deliverable?)
[2] This led to the ever widening number of groups. (More deliverables.)
[3] Some groups then started to argue and propose interfaces that in
some cases had never been widely implemented or thoroughly studied.
[4] Some groups have let company and market pressures direct what should
be an exercise in common sense and good engineering.

It's been a bit more than a year since I looked at any POSIX document.
If memory serves me correctly it's been about 5 years since the first
document was tabled. Has nothing been voted on? When will it all end?
--
=================
"Life is so much more meaningful if you take the time to hunt down and strangle
twits who post blather to inappropriate newsgroups." Henry Spencer


Volume-Number: Volume 27, Number 65

From [e-mail]  Wed Apr  1 22:04:42 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26999; Wed, 1 Apr 92 22:04:42 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29645; Wed, 1 Apr 92 22:04:42 -0500
Newsgroups: comp.std.unix
From: "Robert L. Knighten" <[e-mail]>
Subject: Re: P1003.4[a] Common Reference Ballots (CRBs)
Message-Id: <[e-mail]>
Reply-To: Bob Knighten <[e-mail]>
X-Submissions: [e-mail]
Organization: Intel Supercomputer System Division, Beaverton, OR
References: <[e-mail]>
Date: Wed, 1 Apr 1992 20:53:48 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert L. Knighten)

Draft 12 of the P1003.4 (Realtime Extension) draft standard is in its fourth
ballot (and third recirculation.)  This latest ballot is due at the IEEE
Standards Office on April 10.

Last work the following group met and drafted a Common Reference Ballot which
we hope will be considered by other members of the ballot group before they
submit their own ballots.  Our CRB is included at the end of this message.

The CRB will be submitted as the first 40 items in the ballot of
Robert L. Knighten of Intel Supercomputer Systems Division.

Nawaf Bitar             Kubota-Pacific
David Black             Open Software Foundation
Bob Conti               Digital Equipment Corporation
Bill Cox                Unix Systems Laboratories
Michael Jones           Carneige-Mellon University
Steve Kleiman           SunSoft
Bob Knighten            Intel Supercomputer Systems Division
Jim Pitcairn-Hill       Open Software Foundation
Dave Plauger            Hewlett-Packard
Paul Rabin              Open Software Foundation

This CRB is also available in various forms (ASCII, postscript, troff) by
anonymous ftp from export.ssd.intel.com in the directory /pub/tmp/CRB.

This same group has also done a common reference ballot for the P1003.4a
(Pthreads) draft and that will be available on April 13.
==============================================================================

--------------------------------------------------------------------------
@ all o 1
1: Section all page all line(s) all

OBJECTION:

 The use of errno is a mistake with new functions. Existing POSIX.1 functions
 and their close relatives (e.g. fdatasynch()) should maintain their overall
 structure, as should those tied to existing practice (e.g.  mmap, memlock, et
 al.). The use of errno as a global error indicator in multithreaded
 environments introduces new difficulties.

ACTION:

 New functions (e.g. aio_read, sem_post) should not set a global errno, but
 instead return an error indication as the function return value. We do not
 provide synopses for all such functions, but will on request from the
 technical reviewers.

 Change all new functions such as the aio functions and sem_ functions to
 return an error indication on failure.


--------------------------------------------------------------------------
@ all o 2
2: Section all page all line(s)

OBJECTION:

 We join in UO193.D11. The performance metrics are not consistent, and are not
 appropriate to this standard. Improving something that does not belong does
 not solve the problem. Deleting them will. The problem is not quality but
 timeliness and applicability.

ACTION:

 Delete all performance metrics from D12 and forward the text to a
 benchmarking standards group.


--------------------------------------------------------------------------
@ Introduction c 3
3: Section Introduction page viii line(s) 17-18

COMMENT:

 This makes the same sweeping generalization as in lines 16-17 page 2, and
 should also be amended and clarified.

--------------------------------------------------------------------------
@ 1.1 o 4
4: Section 1.1 page 1 line(s) 5

OBJECTION:

 We join with unresolved objection UO.3.D11. Performance metrics are not the
 appropriate province of a source interface standard. There are groups that
 define benchmarks; the information requested in the performance metrics
 sections (sections 3.9.10, 3.10.5, 6.6.3, 6.7.9, 17.3, 19.2, 20.3, 20.4.6,
 21.4, 21.5.5, 22.3, 23.3, 23.4.6, 24.4, and 24.5.8) should be defined by
 those groups, and not TCOS-sponsored POSIX working groups.

ACTION:

 Delete line 5. In addition, delete all performance metrics as out of scope.


--------------------------------------------------------------------------
@ 1.1 o 5
5: Section 1.1 page 2 line(s) 12-44

OBJECTION:

 We have objected previously to the extremely broad definition of "realtime,"
 and we continue to object vigorously. As part of this objection we point out
 that using names such as "{_POSIX_MAPPED_FILES}" and "{_POSIX_SEMAPHORES}"
 contributes to the vague broad definition of "realtime" being used.

 It is encouraging that application to multiprocessors and networking are
 specifically excluded from scope.  However, the extremely broad nature of
 lines 22-23 renders the limiting to a "...set required to make this standard
 minimally useful to realtime applications on single processor systems" (lines
 12-13) a too-subtle attempt at humor.

 The reviewer's response to unresolved objections (e.g. to W. T. Cox D11
 objection 7, marked "nonresponsive") is itself not a response but an excuse.
 In part, the reviewer said "...the scope is determined by the approved PAR
 and further refined in the informative text of the draft. The items
 [asynchronous I/O and realtime files, among others] ... are well within
 scope."

 We would appreciate the specification of any interface that is not within the
 scope as written in D12 and previous drafts. The only justification that
 appears to serve to delete functionality that is not considered "realtime" is
 an outcry from the balloting group. POSIX.4 appears to take the mechanistic
 (and self- referential) approach that "realtime is anything that's in
 POSIX.4." This absence of anything outside your scope makes it difficult to
 convince the technical reviewers that any particular 'nice interface' is
 inappropriate -- you may only be able to convince them that the time is not
 opportune to slip it past a balloting group.

 Moreover, objections to the broad nature of the scope have been called
 "nonresponsive," and not circulated with other rejected comments to the
 balloting group. What is more responsive to a call to validate a standard
 with broad support than questions about the purpose and scope?

ACTION:

 The scope must be narrowed. One modification that would satisfy this
 objection is to delete line 5 and replace lines 18-26:

 The key elements defining scope are

 (a) defining a sufficient set of functionality to cover a significant part of
 the realtime application domain, and

 (b) ensuring that the simultaneous support of the realtime extensions do not
 impose undue burdens upon implementations that attempt to simultaneously
 support both realtime extensions, POSIX.1 base functionality, and other
 extensions currently being developed to POSIX.1.

 Specifically within the scope is to define interfaces which do not preclude
 high performance implementations on traditional uniprocessor realtime
 systems, but also to extend while focusing on traditional realtime systems
 and needs such as timers, shared memory, scheduling, and interprocess
 communication.

 The establishment of performance metrics are specifically out of scope; text
 for proposed metrics are included in the rationale for each section, and will
 be forwarded to other bodies for standardization.

 The establishment of benchmarks and performance enhancements for file systems
 is also specifically out of scope.

 The signal mechanisms of POSIX.1 and existing implementations are already
 extremely complex.  Adding an additional layer of complexity would not ensure
 that high performance implementations and applications can be built using
 such signal extensions. Accordingly, extensions to the POSIX.1 signals
 mechanism are specifically out of scope.

 Wherever possible, the requirements of other application enrironments are
 included in the interface definition.

 It is beyond the scope of these interfaces to support networking or
 multiprocessor functionality.  (Rationale note: With this limitation on the
 uniprocessor scheduling interfaces, all of the remaining functionality is
 appropriate for closely-coupled multiprocessor systems.)


--------------------------------------------------------------------------
@ 2.2 o 6
6: Section 2.2 page 6 line(s) 24-25

OBJECTION:

 Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
 discussed in the rationale to Chapter 24, so the definition does not belong
 in normative text.

ACTION:

 Delete Lines 24-25.


--------------------------------------------------------------------------
@ 2.2 o 7
7: Section 2.2 page 10 line(s) 178-179

OBJECTION:

 Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
 (according to the index) discussed in the rationale to Chapter 24, so the
 definition does not belong here.

ACTION:

 Delete Lines 178-179.


--------------------------------------------------------------------------
@ 3.3 o 8
8: Section 3.3 page 23-24 line(s) 154-166

OBJECTION:

 SI_TIMER and SI_ASYNCIO and SI_MESGQ require either (1) a kernelized
 implementation or (2) the ability for a user-level implementation to "fake" a
 signal source. The existence of these SI_ values is in conflict with the
 rationale and text for asynch I/O and other functions which say that
 threads-based implementations should not be precluded.

 Sigqueue would have to similarly be a kernel implementation or have a back
 door.

 Similarly, the timer mechanism would have to have a back door way to fake the
 SI_TIMER codes. This has been a system-supplied value that cannot be spoofed
 in the existing practice; a shift to signal-sender- settable values would be
 a breach of existing practice and expectations.

ACTION:

 Delete this entire section; in the alternative, delete lines 157-162 and
 (editorially) all references to the deleted text.


--------------------------------------------------------------------------
@ 3.3 o 9
9: Section 3.3 page 23 line(s) 159-160

OBJECTION:

 Forcing the signal code to return SI_ASYNCIO substantially complicates
 implementations that implement asynchronous I/O by using threads. It forces
 the implementation to modify the signal catching mechanism to cause a special
 code to generated. Moreover, this requirement prevents an implementation
 using threads.

ACTION:

 Delete lines 157-158


--------------------------------------------------------------------------
@ 3.3 o 10
10: Section 3.3 page 21-38 line(s) all

OBJECTION:

 The use of signals for notification of events of interest is a
 low-performance technique. We have made objections whose action, if accepted,
 will eliminate the need for signal notification of events of interest
 including timer firing, asynchronous I/O completion, and IPC message
 notification.

 The general idea is to pass or use a pointer to a function taking the
 appropriate type as a parameter. There are two additional modifications
 needed to support this improvement.

ACTION:

 On p20 line 41, delete the word "signal." (Notifications in exec'd process
 are impossible.)

 On p21 l64 delete the word "signal."

 Delete section 3.3.


--------------------------------------------------------------------------
@ 5.4.5 o 11
11: Section 5.4.5 page 82 line(s) 416-482

OBJECTION:

 We join in UO38.D11 and UO47.D11. The shm_open() and shm_unlink() interfaces
 serve no useful function and introduce needless confusion in code that will
 use different functions for effectively the same purpose.

ACTION:

 Delete shm_open() and shm_unlink().


--------------------------------------------------------------------------
@ 6 o 12
12: Section 6 page all line(s) all

OBJECTION:

 These operations are trivially and more efficiently performed by using
 threads.

ACTION:

 Delete this chapter.


--------------------------------------------------------------------------
@ 6.7 o 13
13: Section 6.7 page 59-77 line(s) 458-1118

OBJECTION:

 This section on asynchronous I/O has improved from previous drafts, but still
 has a number of major problems:

 Notification is far too complex. The alternative of using OPTIONAL realtime
 signals seems peculiar, and a burden on the programmer.

 The focus needs to be on creating interfaces that are implementable using the
 synchronous I/O of threads.

 The reviewer's response to UO148.D11 is interesting, as he says that the
 current chapter is not existing practice. This reinforces other unresolved
 objections that state that the contents of this Section do not reflect
 existing practice.

ACTION:

 Delete this Section.


--------------------------------------------------------------------------
@ 6.7 o 14
14: Section 6.7 page 59-77 line(s) 458-1118

OBJECTION:

 The response to UO148.D11 is not clear; the full text of the objection was
 not presented. Since this text provided an alternative to the Section, UO148
 was responsive, but the balloting group can neither evaluate text it has not
 seen nor appreciate references to text not supplied in the unresolved
 objections list.

ACTION:

 Include the text of unresolved objections per IEEE Standards Board procedures
 and IEEE rules. Deliver the full text of UO148.D11 to the balloting group so
 that references to that text in other unresolved objections make sense.


--------------------------------------------------------------------------
@ 6.7 o 15
15: Section 6.7 page 59-77 line(s) 458-1118

OBJECTION:

 In the event that our previous objection or others calling for deletion of
 this section are not accepted, we make the following objection to the
 notification mechanism. The action also addresses the problems stated in
 unresolved objections numbers 149, 150, 152, 154, 156, and 157.

 The use of optional realtime signals is a burden, as a portable application
 cannot know how much data can be passed, and a specific signal handling
 routine must be scheduled after an expensive signal is sent.

 This is not consistent with "not precluding high-performance implementations"
 as stated on page 2 lines 22-23. Signals by their very nature are low in
 performance, and so-called "realtime signals" do not correct the situation.
 In addition, the atomic update problem cited in, for example, UO.154.D11 and
 the reviewer's response, is addressed.

ACTION:

 A simpler solution, provided in unresolved objection UO148.D11 but
 accidentally deleted by the Unresolved Objections Editor, is to provide a
 function to be called when the I/O operation is completed.  This is an
 element of struct aiocb, and aio_errno and aio_result can be added to struct
 aiocb and the functions aio_error and aio_return can be deleted.

 The new element, aio_notifunction (the name isn't very important, but the
 concept is), is a pointer to a function that takes a pointer to struct aiocb
 as its argument. When the asynchronous I/O operation completes, the function
 referred to by aio_notifunction is called with a pointer to the completed
 aiocb as its parameter. The notification function must be coded as if it has
 no context: the effect of specifying a function that does process control,
 longjmp, or thread control calls that assume a particular environment is
 undefined.

 The rationale should state that the action of calling the notification
 function is the final one performed by the implementation after updating the
 aio_errno and aio_result fields. The notification function may send a signal,
 in which case the result will be as in D12. The notification function can (in
 effect) directly run the signal handler that would deal with the asynch I/O
 completion.

 To make this approach even more flexible, an atomic_t element can be added to
 struct aiocb to atomically mark the aiocb as completed.


--------------------------------------------------------------------------
@ 9.2.1.2 o 16
16: Section 9.2.1.2 page 176 line(s) 93-97

OBJECTION:

 The consensus in P1003.4 is clearly to not use the file system as the name
 space for their handles.  Unfortunately the current "maybe it's in the file
 system and maybe it's not" semantics only confuses the issue further.

ACTION:

 Change these lines to say that if {_POSIX_OBJECTS_ARE_FILES} is defined, then
 the names are true path names; otherwise the indicated things are unspecified.


--------------------------------------------------------------------------
@ 9.2 o 17
17: Section 9.2 page 179 line(s) 211-214

OBJECTION:

 We join in UO142.D11. The variety of message passing systems make this an
 unreasonable requirement on implementations.

ACTION:

 Leave the last close behavior unspecified.


--------------------------------------------------------------------------
@ 17 o 18
18: Section 17 page all line(s) all

OBJECTION:

 Several problems here.

 The apparent reason for this chapter was to replace the System V semaphores.
 The only reason that POSIX.4a semaphores aren't a complete replacement is
 that some machines don't have shared memory.  The embedded case can be
 supported using D11 semaphores with some minor changes.

 Naming semaphores, while odious, is implementable on top of higher
 performance POSIX.4a semaphores.  Simplification via shared memory semaphores
 is a real benefit to users and implementors.

 The goal of being implementable on all systems is met by implementations on
 systems without memory management hardware using pointers in the semaphore
 objects to refer to common synchronization objects, i.e., using an additional
 level of indirection.

ACTION:

 Define shared memory semaphores as defined on the following manual pages.

1.  sem_init()  Initialize a Semaphore



NAME sem_init
DESCRIPTION sem_init() initializes the named semaphore to a known state.
SYNOPSIS

#include <synch.h>

int sem_init(sem_t *sema, int sem_count, int type, void *arg);

PROCESSING sem_init(), initializes the semaphore sema of type type to a known
 state.

The parameter sem_count must be greater than or equal to zero, defines the
initial count of resources protected by the semaphore. Once initialized, the
semaphore can be used any number of times without being re-initialized. A
semaphore should not be re-initialized while threads are waiting at the
semaphore.

If type is USYNC_THREAD the semaphore is initialized for threads within a
single process. Specification of USYNC_PROCESS for the type will initialize
the semaphore for threads across processes.

The arg is reserved for future use.

All operations on semaphores initialized with sem_init() are non-recursive;
the error check is done under the DEBUG option to detect their recursive use.

Statistics and performance data will be collected under the DEBUG option.
OUTPUT On successful completion, sema is initialized and the operation returns
zero. Otherwise, the contents of sema are unchanged and an appropriate error
indication value is returned.  ERROR/DIAGNOSTICS If any of the following
conditions is detected, sem_init() fails and returns the corresponding value:

EINVAL    Invalid argument specified.

EBUSY     An attempt is made to initialize a semaphore while threads are waiting
          at the semaphore.

SEE ALSO sem_wait , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
17.2.1.


2.  sem_wait()  Wait on a Semaphore

NAME sem_wait

DESCRIPTION sem_wait() is used to claim resources under the semaphore's
control.

SYNOPSIS

#include <synch.h>

int sem_wait(sem_t *sema);

PROCESSING sem_wait() acquires sema by decrementing the semaphore value. If
the resulting value is greater than or equal to zero, it returns success
having acquired sema. If the semaphore count is zero upon entry, sem_wait()
suspends execution of the calling thread and places it on a queue associated
with sema where it remains until sema becomes available to the caller (i.e.,
the count is greater than zero), at which point sem_wait() decrements the
count and returns success having acquired sema. (A negative value for the
count is illegal.)

sema must previously have been initialized.

In general, this operation is used to block wait for an event, or when a
critical section is long.

This operation keeps track of statistics and performance data under the DEBUG
option.

If a thread waiting on a semaphore is interrupted by a signal, the signal
handler will run, but sem_wait is always restarted so the semaphore is held on
return.  OUTPUT The operation returns zero if the semaphore is successfully
acquired.  ERROR/DIAGNOSTICS If any of the following conditions is detected,
sem_wait() fails and returns the corresponding value:

EINVAL    Invalid argument specified.

SEE ALSO sem_init , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
17.2.4.

COMMENTS While a sem_wait can be interrupted by a signal or a fork, an
EINTR is never returned to the user: the wait must be restarted.


3.  sem_trywait()  Conditional Locking

NAME sem_trywait

DESCRIPTION sem_trywait() is used to claim resources under the semaphore's
control.

SYNOPSIS

#include <synch.h>

int sem_trywait(sem_t *sema);

PROCESSING sem_trywait() makes a single attempt to acquire the lock sema, but
does not block in the case of a failure. The sema must have been previously
initialized.

This operation keeps track of statistics and performance data under the DEBUG
option.  OUTPUT The operation returns zero if the lock is successfully
acquired and an appropriate error indication value if the lock could not be
acquired.  ERROR/DIAGNOSTICS If any of the following conditions is detected,
sem_trywait() fails and returns the corresponding value:

EINVAL    Invalid argument specified.
EBUSY     The semaphore is in the locked state.

SEE ALSO sem_init , sem_wait , sem_post , sem_destroy , POSIX.4/D12 Section
17.2.4.


4.  sem_post()  Unlock a Semaphore

NAME sem_post

DESCRIPTION sem_post() releases a lock by incrementing the count value of the
semaphore.

SYNOPSIS

#include <synch.h>

int sem_post(sem_t *sema);

PROCESSING sem_post() releases a resource under the semaphore control sema
(increments the semaphore value) acquired by a previous call to either
sem_wait(), or sem_trywait(), and if the new count value is less than or equal
to zero, the next thread waiting at the semaphore will be made runnable.

sem_post() will fail when releasing a resource would over-increment the
semaphore count value and the DEBUG mode is enabled.

This operation keeps track of statistics and performance data under the DEBUG
option.

If more than one thread is waiting, release from the blocked group is
scheduling policy specific for bound threads, and may be dependent on
scheduling parameters for multiplexed threads.  OUTPUT On successful
completion, the operation returns zero.  ERROR/DIAGNOSTICS If any of the
following conditions is detected, sem_post() fails and returns the
corresponding value:

EINVAL    Invalid argument specified.
ENOLCK    The semaphore is not in the locked state.

SEE ALSO sem_init , sem_wait , sem_trywait , sem_destroy , POSIX.4/D12 Section
17.2.5.


5.  sem_destroy()  Destroy a Semaphore

NAME sem_destroy

DESCRIPTION sem_destroy() attempts to destroy a semaphore.

SYNOPSIS

#include <synch.h>

int sem_destroy(sem_t *sema);

PROCESSING sem_destroy() attempts to destroy a semaphore, i.e., free up all
dynamically allocated resources associated with the given semaphore, and/or
invalidates statically allocated object (e.g., it will free up the statistics
buffer dynamically allocated under the DEBUG option).

The parameter sema identifies the semaphore to be destroyed.  OUTPUT On
successful completion, the operation succeeds and returns zero.
ERROR/DIAGNOSTICS If any of the following conditions is detected,
sem_destroy() fails and returns the corresponding value:

EINVAL    Invalid argument specified.
EBUSY     An attempt to destroy semaphore was made while the semaphore was
          locked by another thread.

SEE ALSO sem_init , sem_wait , sem_trywait , sem_post , POSIX.4/D12 Section
17.2.2.

--------------------------------------------------------------------------
@ 17 o 19
19: Section 17 page all line(s) all

OBJECTION:

 sem_lock, sem_trylock, and sem_unlock are bad names for counting semaphores.
 Existing practice would indicate use of either P & V or post and wait. P and
 V are easily confused, therefore...

ACTION:

 Use the names sem_post, sem_wait, and sem_trywait.

--------------------------------------------------------------------------
@ 17.2 o 20
20: Section 17.2 page 89-93 line(s) 12-147

OBJECTION:

 The "harmonization" between .4 semaphores and .4a synchronization primitives
 is inadequate. It forces the application to explicitly name each semaphore
 that span process boundaries. It does not provide adequate protection for
 using inter-process semaphores in that protection cannot be set. In addition
 it conflicts with the obvious way one would use POSIX.4a style semaphores.

ACTION:

 Delete sem_open(), sem_destroy(), and sem_unlink(). Replace them with

  pthread_semattr_init(pthread_semattr_t *attr);
  pthread_semattr_destroy(pthread_semattr_t *attr);
  pthread_semattr_getpshared(pthread_semattr_t *attr, int *pshared);
  pthread_semattr_setpshared(pthread_semattr_t *attr, int pshared);
  pthread_sem_init(pthread_sem_t *sem, pthread_semattr_t *attr);
  pthread_sem_destroy(pthread_sem_t *sem);

 When semaphores are to be shared across process boundaries then they are
 placed in a shared memory object or mapped file. This provides a global name
 for independent processes to use, and it provided a well-defined protection
 mechanism.


--------------------------------------------------------------------------
@ 20 o 21
21: Section 20 page 117 line(s) 2-14

OBJECTION:

 Normative text has been moved to the rationale regarding the following
 behaviors: - writes to memory shared between processes appear in the other
 mapping processes (lines 465- 469).  - behavior on protected or unmapped
 references (lines 486-496).

ACTION:

 Add the lines specified above after line 14.

--------------------------------------------------------------------------
@ 20 o 22
22: Section 20 page 117 line(s) 2-14

OBJECTION:

 The text does not specify that the address of the reference that caused the
 SIGBUS or SIGSEGV should be delivered to the signal handler that specifies
 SA_SIGINFO.

ACTION:

 Add after line 14 something like:

 When a SIGSEGV or SIGBUS is delivered and the SA_SIGINFO flag is set, the
 sival_ptr member of sigev_value shall be set to the address of the reference
 that caused the signal to be generated.  The address may rounded down to the
 nearest {_SC_PAGESIZE} boundary.


--------------------------------------------------------------------------
@ 21 o 23
23: Section 21 page all line(s) all

OBJECTION:

 The scheduling interfaces have become more cumbersome as the drafts have
 progressed. It is time for a simplification.

ACTION:

 Replace this chapter's interfaces with a parallel to the Pthreads POSIX.4a
 CRB proposals. The interfaces that should be supported are

 yield()

 set_sched_attr() for startup

 inheritance from creator

 set_self_scheduler (struct...)

 get_self_scheduler ( struct *... )

 set_scheduler (pid_t, struct...)

 get_scheduler (pid_t, struct *... )

--------------------------------------------------------------------------
@ 21 o 24
24: Section 21 page all line(s) all

OBJECTION:

 We join in Unresolved Objections 81, 89, 95, and 97.

 As stated in UO89.D11, you can't have your cake and eat it too -- SCHED_OTHER
 is not an escape from realtime scheduling. The reviewer's response
 contradicts the statement in D12 that SCHED_OTHER may be the same as either
 SCHED_FIFO or SCHED_RR. You can't have it both ways...

 UO97.D11 brings up the identification of schedulers problem. A simple
 implementation could define SCHED_OTHER to be zero, SCHED_FIFO to be zero,
 and SCHED_RR to be one. How do you tell what the result of a getscheduler()
 call is? Remember, the value of SCHED_OTHER is a compile-time constant.


ACTION:

 Change all occurrences of SCHED_OTHER to SCHED_DEFAULT. In the alternative,
 define a new interface sched_default() which returns an indicator of the
 default scheduler for the implementation. This should probably be a string,
 but a name would be even better. This eliminates the need for a SCHED_OTHER
 constant.


--------------------------------------------------------------------------
@ 21 o 25
25: Section 21 page all line(s) all

OBJECTION:

 The use of SCHED_OTHER is confusing. SCHED_OTHER is simply a placeholder for
 "some scheduling algorithm that may be different or not different from
 SCHED_FIFO and SCHED_RR". This suggests both that SCHED_OTHER is a name for
 some specific scheduling algorithm AND that SCHED_OTHER is a name for some
 selectable scheduling algorithm that may be different from SCHED_FIFO and
 SCHED_RR.

 Unfortunately, SCHED_OTHER can't be both. The apparent meaning is of some
 system-defined policy that is neither FIFO nor RR, but over-generalization in
 the text of this section makes that incorrect as well.  A more appropriate
 name is "SCHED_DEFAULT." The reviewer's comments on UO81.D11 is not
 persuasive. Perhaps another name would be acceptable to the balloting group?
 We believe that SCHED_DEFAULT is the best that has been proposed so far.

ACTION:

 Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter.

--------------------------------------------------------------------------
@ 22 o 26
26: Section 22 page 168- line(s) 36ff

OBJECTION:

 Timer firing notification should be should be be a function as in our
 proposal for asynch I/O. This style of notification allows flexible
 prioritization of timer completion events without the overhead of sending a
 signal.

ACTION:

 A simpler solution, similar to that provided in unresolved objection
 UO148.D11 but accidentally deleted by the Unresolved Objections Editor, is to
 provide a function to be called when the timer fires.

 Replace the evp argument with a pointer to a function with a single parameter
 of type clock_t. Change p171, lines 146-148 and 153-162 to match. Correct the
 prototype.


--------------------------------------------------------------------------
@ 22.2 c 27
27: Section 22.2 page 171 line(s) 137

EDITORIAL COMMENT:

 The type of the *evp parameter is missing. If our other objections are not
 accepted, this should read ...  struct sigevent *evp.


--------------------------------------------------------------------------
@ 23 o 28
28: Section 23 page all line(s) all

OBJECTION:

 IPC message notification should be a function as in our proposal for asynch
 I/O. This style of notification allows flexible prioritization of IPC
 completion events without the overhead of sending a signal.

ACTION:

 Change the notification parameter on p191 lines 16-17 to type pointer to
 function with parameter mqd_t.  Change lines 347-354 to match the new meaning
 for notification.


--------------------------------------------------------------------------
@ 23 o 29
29: Section 23 page all line(s) all

OBJECTION:

 The message-received notification is within a process, and (rather than the
 optional realtime signals) should be as we have proposed for asynch I/O.

--------------------------------------------------------------------------
@ 23 o 30
30: Section 23 page 191-210 line(s) 1-656

OBJECTION:

 In reference to D11 Unresolved Objections 133, 142:

 The interfaces in this chapter are not based on current practice. In
 particular, none use the file system as the name space for their handles, for
 good reason. It confuses the semantics of both the message queues and the
 file system and is not extensible over the network. The current "maybe it's
 in the file system and maybe it's not" semantics only confuses the issue
 further.

 I believe that it is possible to meet all the requirements expressed by the
 rationale by minimal extensions to the BSD sockets interface or the X/Open
 XTI interface. Indeed, the working group has recognized this possibility and
 asked .12 to do so. It should be possible to meet the valid real time
 requirements through extensions to existing, more general interfaces, rather
 than through introduction of a new (although much improved from previous
 drafts!) set of interfaces.

 At the very least, any new .4 IPC interface should be implementable entirely
 on top of sockets, or in terms of threads and shared memory.

 In summary, We believe that no convincing rationale has been presented for
 the addition of completely new IPC interfaces.

ACTION:

 The proposed interfaces should be replaced with one based on an existing
 interface, ideally one that has potential to be used in a distributed
 environment, including those in which the file systems are not shared (i.e.
 are not syntactically linked with the file system). Our preferred candidate
 would be to utilize the BSD sockets and X/Open XTI interfaces as being
 standardized by .12, with the addition of a real time protocol.

 Alternately, this objection can be satisfied by deleting the IPC chapter.


--------------------------------------------------------------------------
@ 23.1.1 o 31
31: Section 23.1.1 page 192 line(s) 26-28,46-53

OBJECTION:

 In reference to D11 Unresolved Objections 134, 136:

 The mq_sendwait, mq_rcvwait, and mq_curmsgs fields cannot be counted on to
 remain fixed between a reading of the fields and any subsequent action within
 a program. Therefore, it's not clear what use any program could reliably make
 of this data. The application can only tune itself if it has control over all
 consumers of the queue and diagnosis is not in the province of POSIX.

 Also, counting the number of waiting processes precludes implementations in
 shared memory using pthreads-like synchronization primitives. First, some
 synchronization primitives don't keep track of the number of sleeping
 processes (e.g. slow spin). Also, it is difficult or impossible to
 distinguish multiple sleeping threads within a process from separate sleeping
 processes.

ACTION:

 These fields should be removed.


--------------------------------------------------------------------------
@ 23.2 c 32
32: Section 23.2 page 201 line(s) 336

EDITORIAL COMMENT:

 The type of the *notification parameter is missing. If our other objections
 are not accepted, this should read ... struct sigevent *notification.


--------------------------------------------------------------------------
@ 23.2.7 o 33
33: Section 23.2.7 page 202-203 line(s) 370-426

OBJECTION:

 In reference to D11 Unresolved Objection 140:

 The function mq_setattr() provides the capability to dynamically modify the
 message queue attributes, such as the message maximum size or maximum number
 of messages. Although this functionality represents a higher degree of
 flexibility, in our opinion, this flexibility does not justify the efficiency
 burden imposed on the implementation that has to deal with the possibility of
 dynamic sizing of the message queue objects. This represents a source for
 more indeterminate time in the message queuing and dequeuing operations
 (which could be concurrently executed with this dynamic reconfiguration of
 the message queue) and a source of complexity and inefficiency for the
 implementation.

 Also, making the ability to set the max number of messages and max message
 size implementation defined only makes this ability unusable by portable
 applications, and points out that there is no true need for this ability.

ACTION:

 Delete the mq_setattr() function, and make the queue attributes static.


--------------------------------------------------------------------------
@ 24 o 34
34: Section 24 page all line(s) all

OBJECTION:

 Realtime files confuse the desired objective -- predictable performance --
 with mechanisms that have historically been used to obtain predictable
 performance from disks and/or file systems. This confusion is most evident in
 the requirements laid on implementations to place data and to organize
 descriptive information in particular ways. Current disk subsystem
 technology, including SCSI, RAID, advanced striping, journaling, and recovery
 technology render much of the low-level detail obsolescent if not obsolete.

 The specification of low-level architecture and behavior stifle innovation
 and leave little room to achieve the real goals of fast, predictable access
 to data.

ACTION:

 Delete this chapter. In the alternative, define in rationale only performance
 metrics for vendor/technology comparison, and forward them to a benchmarking
 group.

 Alternatives using fcntl() to pass hints on access characteristics are
 presented in other objections.


--------------------------------------------------------------------------
@ 24 o 35
35: Section 24 page 228-230 line(s) 578-625

OBJECTION:

 rf_getbuf and rf_freebuf are new interface that are not needed. The usage can
 be replaced with aligned versions of malloc as used in SunOS and other
 systems.

ACTION:

 Use this existing practice interface or delete this text.


--------------------------------------------------------------------------
@ 24 o 36
36: Section 24 page all line(s) all

OBJECTION:

 The interfaces presented in Section 24 are overly complex to meet the stated
 needs. The stat structure (defined in <stat.h>) can return the suggested I/O
 blocksize in the field st_blksize. This allows determination on a
 file-by-file basis.

 The existing interface fcntl() can be used to advises the implementation
 about the expected usage pattern for a file descriptor. The arguments that
 fcntl() is not type-safe and should be discouraged are not compelling --
 fcntl has been a general file management interface for many years, and
 programmers have learned to deal with its impurities.

 We differ with unresolved objection UO178.D11 in that we would use only
 F_ADVISE, deleting F_DONTNEED and F_WILLNEED from that objection. We find
 that the use of struct flock is unnecessary overloading.

ACTION:

 Follow the prescription in UO178.D11 with the exception of F_DONTNEED and
 F_WILLNEED.


--------------------------------------------------------------------------
@ 24 o 37
37: Section 24 page all line(s) all

OBJECTION:

 We partially join in unresolved objections UO168.D11, UO171.D11, UO177.D11,
 and UO178.D11. So- called "direct I/O" does not belong here. It is
 disingenuous to claim (response to UO171.D11) that buffering the requests
 anyway is an acceptable implementation. We challenge the technical reviewer
 to give a cogent explanation of how manipulating the caching strategy and the
 buffering strategy separately will give DETERMINISTIC and PORTABLE behavior.

 This nonsense is not consistent with the claimed rationale for providing the
 functionality, and tries to solve problems more appropriately solved by
 standardized performance metrics/methodology and market pressures.

 Moreover, capabilities for establishing similar functionality are already
 available on existing UNIX Systems, e.g., use of raw disk partitions.
 Complicating the I/O subsystem by adding per-file tunable buffering seems a
 mistake.

ACTION:

 Delete all references to "direct I/O" including these lines, definitions, and
 rationale.


--------------------------------------------------------------------------
@ 24 c 38
38: Section 24 page 24.5 line(s) 234

EDITORIAL COMMENT:

 If our objections relating to direct I/O are accepted, direct I/O is not used
 in normative text, so this reference in the rationale should be deleted.

ACTION:

 Delete lines 785-787.


--------------------------------------------------------------------------
@ 24 o 39
39: Section 24 page all line(s) all

OBJECTION:

 We join in unresolved objections UO169.D11, 170-175, 179, and 180.

 The reviewer's response to UO170.D11 adds useful information on some existing
 systems that support "these facilities." The reviewer later mentions that
 Digital has implemented D9 interfaces on a version of VMS, which further
 weakens the claim that "these facilities" are necessary and broadly
 supported. The dismissal of "realtime file systems" ignores the typical
 implementation of files on modern operating systems using a Virtual File
 System sort of architecture. The mixing of multiple types of files in a
 directory hierarchy may preclude a high performance implementation and may,
 in fact, affect all uses of files due to the support of so-called "realtime
 files."

 The argument in UO172.D11 is compelling. Not only are the facilities
 insufficient to meet the claimed need, they cannot be made complete by
 breaking up the capabilities buffer.

 The reviewer's response to UO173.D11 is identical to that for UO172.D11, and
 does not address the point of UO173. What portable actions can be taken by an
 application? The capabilities buffer is certainly "a zoo" even after its
 separation. The syntactic expression does not serve to hide semantic
 (over-)complexity.

 We have observed elsewhere that the 'aligned allocator' rf_getbuf should be
 replaced with an aligned malloc as used in SunOS. (UO174.D11)

 UO175.D11 and the essentially identical UO179.D11 give additional support to
 our general comments on this Section.

ACTION:

 Delete this chapter. Forward the performance metrics to a standards and/or
 benchmarking group. (Retain the benchmarks in the rationale if desired.)


--------------------------------------------------------------------------
@ 24.3 o 40
40: Section 24.3 page 228 line(s) 578-625

OBJECTION:

 The functions rf_getbuf() and rf_freebuf() should be compatible with existing
 practice for aligned allocation.

ACTION:

 Replace these names with valloc() as valloc(size) does an aligned allocation.

--------------------------------------------------------------------------
--
Robert L. Knighten                 | [e-mail]
Intel Supercomputer Systems Division |
15201 N.W. Greenbrier Pkwy.         | [phone]
Beaverton, Oregon  97006         | [phone] [FAX]


Volume-Number: Volume 27, Number 66

From [e-mail]  Thu Apr  2 18:59:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05230; Thu, 2 Apr 92 18:59:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27287; Thu, 2 Apr 92 18:58:58 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: Re: Is POSIX a waste?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 2 Apr 1992 20:42:22 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

In <[e-mail]> [e-mail] (Tom Glinos) writes:

>At the risk of being flamed back into the stone age I'll offer
>the opinion that the whole POSIX exercise has been a waste, for
>the following reasons.

No flames. :-)
I'll leave that to better flamers than I....

>[1] It's never been clear to me what the original POSIX proposals were
>supposed to define and accomplish. (What is the deliverable?)

Where/when are you referring to?
The /usr/group standard (POSIX.1's ancestor) had a very definate
scope/purpose. Likewise, POSIX.1 has a similar well defined scope/purpose.
For that matter, so does each and every piece of POSIX. They have all had
to go through the IEEE's review process for new proposed work items.

``This part of ISO/IEC 9945 defines a standard operating system interface
  and environment to support application portability at the source-code
  level.  It is intended to be used by both applications developers and
  system implementors.''

First page, first paragraph of the normative part of the POSIX.1 standard.
Similar statement as the first paragraph of POSIX.2, and so on.
Each document that is either a real standard, or fairly far along in the
development process is clearly declared.

>[2] This led to the ever widening number of groups. (More deliverables.)

No. Each project belonging to each working group serves a clearly defined
purpose. The breadth of the entire POSIX family of standards is very large,
but then the
book shelf space of a lot of operating systems User/Programmer documentation
can be considerable as well. (VMS's historical ``wall of orange'' for
instance.)

>[3] Some groups then started to argue and propose interfaces that in
>some cases had never been widely implemented or thoroughly studied.

Yep. Happens. Which is why there is a consensus based process in place to
build de jure standards.  And there are people who regularly try to
subvert it. Also happens.  Other people try and make it work. Sooner or later
it all balances out. Sort of like the informal consensus process which
surrounds the formal one.

P.J. Plauger writing about the politics of standards
[specifically the C standard] talked about good politics (when things are
going your way) versus ``Damned'' politics (when you're losing the fight.)
It's part of the process. But then it's part of any process where there are
a lot of people with a diverse set of experiences trying to build
something. [No ``blind men identifying an elephant'' jokes, please.]

And sometimes you lose. Hopefully, they aren't in places that will break
the standard badly enough to cast into doubt the entire standard or the
process that built it.

>[4] Some groups have let company and market pressures direct what should
>be an exercise in common sense and good engineering.

There are rules in the IEEE standards process to do with the balance
of membership in working groups (building draft documents) and balloting
groups (commenting on those drafts). They cannot be heavily weighted
towards Users OR Vendors.

There is a balance involved between users (wanting the sun and the stars) and
the vendors who can build something efficient (that will get you to the moon.)
Somewhere in the middle lies reality.

It's all about market pressure and economics at some level. If you want
great solutions based on ``common sense and good engineering'', live in a
research lab, which is probably the closest you'll get to such a perfect
world.

>It's been a bit more than a year since I looked at any POSIX document.
>If memory serves me correctly it's been about 5 years since the first
>document was tabled.

IEEE 1003.1-1988

>Has nothing been voted on?

IEEE 1003.1-1990 == ISO/IEC 9945-1:1990
IEEE 1003.3-1991
In ballot:
POSIX.2 *
POSIX.2a *
POSIX.3.1
POSIX.4 *
POSIX.4a
POSIX.5 *
POSIX.6
POSIX.9 *
POSIX.13
* -- Optimistically, almost done.

>When will it all end?
Wont. Standards change as technology changes. Not as rapidly, but they change.
New standards are added. Out-of-date standards are removed. Bad standards die.

>"Life is so much more meaningful if you take the time to hunt down and
> strangle twits who post blather to inappropriate newsgroups." Henry Spencer

Yes.

Cheers,
stephe

                   ``So there *is* a God. What's your point?''


Volume-Number: Volume 27, Number 67

From [e-mail]  Fri Apr  3 05:44:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07895; Fri, 3 Apr 92 05:44:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21866; Fri, 3 Apr 92 05:44:53 -0500
Newsgroups: comp.std.unix
From: Andy Tanenbaum <[e-mail]>
Subject: Query about POSIX rmdir system call
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Date: Fri, 3 Apr 1992 10:05:19 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andy Tanenbaum)

Does anyone know what the following program is supposed to do according
to P1003.1 and why? If the rmdir works, how can things like this be
implemented in general?

  main()
  {
  #include <unistd.h>

    mkdir ("D", 0777);
    rmdir("D/.");
  }


Andy Tanenbaum ([e-mail])


Volume-Number: Volume 27, Number 68

From [e-mail]  Fri Apr  3 16:27:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13495; Fri, 3 Apr 92 16:27:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22614; Fri, 3 Apr 92 16:27:29 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Is POSIX a waste?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 3 Apr 1992 10:29:26 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Stephen Walli) writes:
>There is a balance involved between users (wanting the sun and the stars) and
>the vendors who can build something efficient (that will get you to the moon.)
>Somewhere in the middle lies reality.

So, the standards drop you into the asteroid belt?

Seriously, a good standard (one that canonicalized proven principles)
serves as a platform for further development, while a bad standard
(one that locks users into inferior technological solutions) serves
to stifle innovation.  In the opinion of many, several of the newer
POSIX standards fall into the latter category.  And they cannot just
be ignored, because both users and vendors have made advance
commitments to adhere to any and all such standards.  Thus even bad
standards leave an indelible mark on computing.


Volume-Number: Volume 27, Number 69

From [e-mail]  Fri Apr  3 16:27:33 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13536; Fri, 3 Apr 92 16:27:33 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22653; Fri, 3 Apr 92 16:27:38 -0500
Newsgroups: comp.std.unix
From: Cameron Simpson <[e-mail]>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: CS&E Computing Facility, Uni Of NSW, Oz
References: <[e-mail]> <[e-mail]>
Date: Sat, 4 Apr 1992 03:11:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Cameron Simpson)

[e-mail] (David J. MacKenzie) writes:
>> What does
>>     echo a # b c
>> produce if typed at an interactive shell?  There is one sh-style shell out
>> in the wide world that will echo 'a # b c' instead of just 'a' and I'd like
>> to know if this behavior is POSIX-compiliant.
[...]
>The only explicit mention of `#' for the shell in p1003.2a is in the
>description of the Vi editing mode.

I hope not. Every Bourne shell I've ever used considered that any word
commencing with an unquoted # introduces a comment extending through until
the end of the line. If POSIX breaks this (even in interactive mode) lots
of people will be pissed. Me for one.
    - Cameron Simpson
      [e-mail]

P.S.    Consider the chaos when it's no longer safe to cat a script and
    cut/paste some of it into some shell window to get something done.
    Not a great example, but convenient and not uncommon in a windowing
    environment. Changing the rules for interactive mode is something to
    approach with fear and trepidation.


Volume-Number: Volume 27, Number 70

From [e-mail]  Fri Apr  3 16:27:39 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13543; Fri, 3 Apr 92 16:27:39 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22686; Fri, 3 Apr 92 16:27:45 -0500
Newsgroups: comp.std.unix
From: Fred Zlotnick <[e-mail]>
Subject: Re: Query about POSIX rmdir system call
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]>
Date: Fri, 3 Apr 1992 18:21:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Fred Zlotnick)

In article <[e-mail]> [e-mail] (Andy Tanenbaum) writes:
>Does anyone know what the following program is supposed to do according
>to P1003.1 and why? If the rmdir works, how can things like this be
>implemented in general?
>
>  main()
>  {
>  #include <unistd.h>
>
>    mkdir ("D", 0777);
>    rmdir("D/.");
>  }

First, my personal opinion:  The directory "D" in the current directory
(the one just created by the mkdir() call) should be removed.  The relevant
clause in 1003.1-1990 is 2.3.6, "pathname resolution", which says in part:

    Pathname resolution is performed for a process to resolve a
    pathname to a particular file in a file hierarchy...

    Each filename in the pathname is located in the directory
    specified by its predecessor.... If the pathname does not
    begin with a slash, the predecessor of the first filename
    of the pathname is taken to be the current working directory
    of the process...

    The special filename, dot, refers to the directory specified
    by its predecessor.

Collective these imply (IMHO) that the pathname "D/." resolves to "D" in
the current directory.  However, as Bob Lenk once said in this newsgroup,
"It is worth pointing out that official interpretations of an IEEE
standard can only be issued by the IEEE."

Having said all that, I tried this on six different systems, at least three
of which claim to be POSIX.1 conforming.  It failed on all of them, with
errno = EINVAL on five of the six.  EINVAL is not given as one of the errno
values for any error specified by POSIX.1.

The P1003.3.1 Draft 13 test assertions for clause 2.3.6 specify behavior
for rmdir (among other functions) for pathnames that have a "." as an
initial component or an intermediate component, but not as a final component.
That's no help.  I think it's time for an official interpretation.

Incidentally, the 0777 in the mkdir call is not POSIX-portable.  It will,
of course, work on all known systems (known to me, anyway) but the ugly
construct (mode_t)(S_IRWXU | S_IRWXG | S_IRWXO) is its POSIX-portable
replacement.
----
Fred Zlotnick            |  POSIX is coming! POSIX is coming!
[e-mail]        |          -- Stephen Walli
...!{uupsi,ames}!mindcrf!fred    |
#include <std/disclaimer>    |


Volume-Number: Volume 27, Number 71

From [e-mail]  Sat Apr  4 16:02:40 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22601; Sat, 4 Apr 92 16:02:40 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16124; Sat, 4 Apr 92 16:02:45 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Is POSIX a waste?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 3 Apr 1992 00:38:56 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Tom Glinos) writes:
>[1] It's never been clear to me what the original POSIX proposals were
>supposed to define and accomplish. (What is the deliverable?)

The "original POSIX proposals" were to codify existing
practice on UNIX and UNIX-like systems in a vendor-neutral
form.  The deliverable is the POSIX.1 standard (ISO/IEEE
9945-1, 1990).

>[2] This led to the ever widening number of groups. (More deliverables.)

That's the price of success.  Vendor-neutral, standard
specifications were found to be desirable in fields beyond
the scope of POSIX.1.

>[3] Some groups then started to argue and propose interfaces that in
>some cases had never been widely implemented or thoroughly studied.

Some of this was necessary because existing practice
included conflicting implementations, some of it was
necessary because existing practice was based on incomplete
or non-extensible abstractions, and some was gratuitous.
It's a bit of an exaggeration to blow this issue up and say
that it invalidates the POSIX standards process.

>[4] Some groups have let company and market pressures direct what should
>be an exercise in common sense and good engineering.

This complaint contradicts [3], above.  The cases where
POSIX committees have been criticized for being too
innovative have resulted from attempts to use common
sense and engineering judgement where others would have
preferred simple description of existing implementations,
which are blessed by the companies that own them and
by the marketplace (installed base).

>If memory serves me correctly it's been about 5 years since the first
>document was tabled. Has nothing been voted on?

POSIX.1 has been a standard since August, 1988.  POSIX.3
has been a standard for a little more than a year.

>When will it all end?

When the market for portable software disappears.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 27, Number 72

From [e-mail]  Sun Apr  5 17:48:57 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05321; Sun, 5 Apr 92 17:48:57 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21962; Sun, 5 Apr 92 17:48:55 -0400
Newsgroups: comp.std.unix
From: Andy Tanenbaum <[e-mail]>
Subject: Query about implementing FIFOs
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Date: Sun, 5 Apr 1992 21:08:56 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andy Tanenbaum)

Suppose a process opens (an empty) FIFO and writes some data to it.
Then it forks.  The parent goes to sleep for a while, holding the FIFO
open.  The child reads 5 bytes, then closes the FIFO.  Then it opens the
FIFO again and reads 5 more bytes.

I presume POSIX requires that the second read return bytes 5-9 of the
original write, but how can this be implemented in a reasonable way?
There is no place in the i-node to keep track of the current file position,
and copying the FIFO to shift everything down 5 bytes doesn't sound like
much fun.  Trying to figure out where the start of data is from the parent's
file pointer doesn't help, and besides, if the parent had closed too, that
wouldn't be there.  How is this normally implemented?

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 27, Number 73

From [e-mail]  Wed Apr  8 02:17:06 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24034; Wed, 8 Apr 92 02:17:06 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11557; Wed, 8 Apr 92 02:17:04 -0400
Newsgroups: comp.std.unix
From: John Gottschalk <[e-mail]>
Subject: threads library
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Prentice Centre, University of Queensland
Date: Wed, 8 Apr 1992 05:26:50 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John Gottschalk)

I am considering using the SUN light-weight process package (a threads library)
for some software development. I would like to know if there are
any standards for a threads library, so that the software can be fairly
portable. Do SVR4 or OSF offer a threads library?

            -- regards, John Gottschalk

John Gottschalk ([e-mail])
Centre for Information Technology Research,
The University of Queensland, 4072,
Brisbane, Queensland, Australia,
[phone] (phone), [phone] (fax)

Volume-Number: Volume 27, Number 74

From [e-mail]  Wed Apr  8 02:22:26 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24112; Wed, 8 Apr 92 02:22:26 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12137; Wed, 8 Apr 92 02:22:21 -0400
Newsgroups: comp.std.unix
From: Andrew Josey <[e-mail]>
Subject: submission for comp.std.unix
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 7 Apr 1992 15:42:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Josey)

        X/OPEN USERS GROUP MEETING

DATE: May 21st 1992

VENUE: X/Open offices Washington DC, USA

X/Open is  running a series of one day user group meetings to provide
information and announcements on the X/Open branding programme
and the use of VSX (the Verification Suite for X/Open).

The second of these meetings will take place at X/Open's offices in
Washington D.C.  on May 21st.

All prospective users and interested parties are invited to attend.
Attendees will also include current VSX licensee's, distributors, and X/Open
company users.

* DRAFT AGENDA

0930-10.00    Welcome and introductions    James Andrews

1000-1100    VSX its development and implementation    Tom Norris

Tom will outline the VSX development process, and explain in simple
terms how VSX works. Tom will also give a brief tutorial on the Test
Environment Toolkit and its role in future test strategy.

1100-1200    Branding UNIX System V Release 4    Andrew Josey

Andrew will relate his experience in branding UNIX SVR4.  His talk
will include illustrations of the practical problems of using VSX for testing
prior to applying for the brand.

1200-1300    Making an application for branding    Jenny Wilkinson

Jenny will explain how to put together a branding application that meets
X/Open requirements. She will outline the activities she undertakes in
processing the branding application and the typical problems encountered
and how they can be avoided.

1300-1400    Lunch

1400-1500    Test tool quality assurance and     James Andrews
        test developments.

James will outline the quality assurance techniques used by X/Open to
qualify test tools prior to their release.  He will summarise all the current
release programs including a description of the test technology currently
under development.  He will also explain the quality assurance methodologies
and procedures associated with branding to deliver to Users the
confidence in the conformity of branded products.

1500-1600    XPG4 branding and application         James de Raeve
            registration launch

James will explain X/Open's future plans for the branding program, in
particular the launch of XPG4. He will highlight the expected differences
between the XPG3 and XPG4 brands. James will also explain the application
registration scheme.

1600-1700    A test centre perspective        TBD

An X/Open test centre will present their experiences in the
distribution of VSX and formal testing.

1700-1730    Questions and answers    All Speakers

All speakers will allow some time for questions, however this session
gives you an opportunity to ask any burning question not answered
earlier.

1730-1745    Summing up and Close of meeting    James Andrews


* List of Speakers

Tom Norris is product manager of VSX at X/Open's VSX developer and
manufacturer, UniSoft

Andrew Josey manages the branding of UNIX System Laboratories'
products including System V Release 4. He is the UNIX International
representative at the X/Open Verification Working Group.

Jenny Wilkinson is X/Open's branding administrator. She manages all
aspects of the processing of branding applications.

James Andrews is X/Open's Conformance Quality Manger. He is
responsible for the quality of the branding program and project manages
all test tool procurements and developments.

James de Raeve is X/Open's Conformance Strategy Manager.  He is
responsible for all aspects of the branding programme and in particular its
direction and development


* TO RESERVE A PLACE

Lunch will be provided and there will be a fee for attendance of US$350.
Please let Anna Tomasello at X/Open know if you would like us
to reserve a place for you on this event. Closing date for
applications is Friday May 8th.


Anna Tomasello                                        X/Open Company Limited
Technical Administrator                             Apex Plaza, Forbury Road
EMail:[e-mail]                      Reading, England, RG1 1AX
FAX: +(44) (0)734 500110                            Tel: +(44) (0)734 508311


Volume-Number: Volume 27, Number 74

From [e-mail]  Wed Apr  8 02:22:28 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24117; Wed, 8 Apr 92 02:22:28 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12142; Wed, 8 Apr 92 02:22:24 -0400
Newsgroups: comp.std.unix
From: Andrew Josey <[e-mail]>
Subject: submission for comp.std.unix
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 7 Apr 1992 15:42:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Josey)

        X/OPEN USERS GROUP MEETING

DATE: May 21st 1992

VENUE: X/Open offices Washington DC, USA

X/Open is  running a series of one day user group meetings to provide
information and announcements on the X/Open branding programme
and the use of VSX (the Verification Suite for X/Open).

The second of these meetings will take place at X/Open's offices in
Washington D.C.  on May 21st.

All prospective users and interested parties are invited to attend.
Attendees will also include current VSX licensee's, distributors, and X/Open
company users.

* DRAFT AGENDA

0930-10.00    Welcome and introductions    James Andrews

1000-1100    VSX its development and implementation    Tom Norris

Tom will outline the VSX development process, and explain in simple
terms how VSX works. Tom will also give a brief tutorial on the Test
Environment Toolkit and its role in future test strategy.

1100-1200    Branding UNIX System V Release 4    Andrew Josey

Andrew will relate his experience in branding UNIX SVR4.  His talk
will include illustrations of the practical problems of using VSX for testing
prior to applying for the brand.

1200-1300    Making an application for branding    Jenny Wilkinson

Jenny will explain how to put together a branding application that meets
X/Open requirements. She will outline the activities she undertakes in
processing the branding application and the typical problems encountered
and how they can be avoided.

1300-1400    Lunch

1400-1500    Test tool quality assurance and     James Andrews
        test developments.

James will outline the quality assurance techniques used by X/Open to
qualify test tools prior to their release.  He will summarise all the current
release programs including a description of the test technology currently
under development.  He will also explain the quality assurance methodologies
and procedures associated with branding to deliver to Users the
confidence in the conformity of branded products.

1500-1600    XPG4 branding and application         James de Raeve
            registration launch

James will explain X/Open's future plans for the branding program, in
particular the launch of XPG4. He will highlight the expected differences
between the XPG3 and XPG4 brands. James will also explain the application
registration scheme.

1600-1700    A test centre perspective        TBD

An X/Open test centre will present their experiences in the
distribution of VSX and formal testing.

1700-1730    Questions and answers    All Speakers

All speakers will allow some time for questions, however this session
gives you an opportunity to ask any burning question not answered
earlier.

1730-1745    Summing up and Close of meeting    James Andrews


* List of Speakers

Tom Norris is product manager of VSX at X/Open's VSX developer and
manufacturer, UniSoft

Andrew Josey manages the branding of UNIX System Laboratories'
products including System V Release 4. He is the UNIX International
representative at the X/Open Verification Working Group.

Jenny Wilkinson is X/Open's branding administrator. She manages all
aspects of the processing of branding applications.

James Andrews is X/Open's Conformance Quality Manger. He is
responsible for the quality of the branding program and project manages
all test tool procurements and developments.

James de Raeve is X/Open's Conformance Strategy Manager.  He is
responsible for all aspects of the branding programme and in particular its
direction and development


* TO RESERVE A PLACE

Lunch will be provided and there will be a fee for attendance of US$350.
Please let Anna Tomasello at X/Open know if you would like us
to reserve a place for you on this event. Closing date for
applications is Friday May 8th.


Anna Tomasello                                        X/Open Company Limited
Technical Administrator                             Apex Plaza, Forbury Road
EMail:[e-mail]                      Reading, England, RG1 1AX
FAX: +(44) (0)734 500110                            Tel: +(44) (0)734 508311


[ Apologies if this gets out twice -- mod ]

Volume-Number: Volume 27, Number 75

From [e-mail]  Thu Apr  9 17:14:22 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07962; Thu, 9 Apr 92 17:14:22 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20173; Thu, 9 Apr 92 17:14:28 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about implementing FIFOs
Message-Id: <[e-mail]>
Article-I.D.: uunet.1992Apr9.193728.27989
References: <[e-mail]>
Organization: U of Toronto Zoology
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Apr 92 16:58:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

>Submitted-by: [e-mail] (Andy Tanenbaum)
>There is no place in the i-node to keep track of the current file position,
>and copying the FIFO to shift everything down 5 bytes doesn't sound like
>much fun.  Trying to figure out where the start of data is from the parent's
>file pointer doesn't help, and besides, if the parent had closed too, that
>wouldn't be there.  How is this normally implemented?

Note that 6.3.1.2 says that if all file descriptors associated with a FIFO
have been closed, any remaining data goes away.  The issue arises only if
somebody has kept the FIFO open, so the usual approach is for the kernel
to retain some extra information in core for an *open* FIFO.  Andy is
correct that file pointers aren't useful, if only because there can be
more than one of them if several processes are involved; the extra
information has to be associated with the (in-core) inode, not with a
particular customer.
--
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  [e-mail]  utzoo!henry


Volume-Number: Volume 27, Number 76

From [e-mail]  Thu Apr  9 18:58:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12047; Thu, 9 Apr 92 18:58:01 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19823; Thu, 9 Apr 92 18:58:04 -0400
Newsgroups: comp.std.unix
From: Bob Lenk <[e-mail]>
Subject: Re: Report on POSIX.6, Jan. 1992
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Technologies, Inc
References: <[e-mail]>
Date: Thu, 9 Apr 1992 22:45:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Lenk)

In article <[e-mail]> [e-mail] (Stephen Walli)
writes:

>          Taken to  an  extreme, this  means  that regardless  of  the
>          ballot pool  size,  if 3  people  vote affirmative, 1  votes
>          negative and the  rest abstain, the  initiative passes.  The
>          moral of the story is:  abstain only as a last resort, there
>          may be deleterious side effects.

While this is true, I wouldn't necessarily draw the conclusion that I
infer (vote negative rather than abstain).  Remember that a negative
ballot must contain specific objections which, if addressed, would make
the ballot affirmative.  Thus a negative ballot is actually an
affirmative response for the subsequent ballot with preconditions.  In
other words, a negative ballot which doesn't cover all of its
submitter's real objections to the standard could have even more
"deleterious side effects".

Perhaps the conclusion I inferred was not intended.  Another possible
conclusion is "do not submit a ballot rather than abstain".  I agree
that it makes sense not to join a balloting group rather than to join
and abstain.  If one has chosen to join, I think it is appropriate to
submit a ballot.

        Bob Lenk
        [e-mail]
        {uunet,hplabs}!fc.hp.com!rml


Volume-Number: Volume 27, Number 77

From [e-mail]  Mon Apr 13 19:41:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20036; Mon, 13 Apr 92 19:41:32 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09275; Mon, 13 Apr 92 19:41:24 -0400
From: Joseph Berry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: threads library
Message-Id: <[e-mail]>
Article-I.D.: ftp.sd58rINNbb
References: <[e-mail]>
Organization: UUNET Technologies, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 13 Apr 92 23:25:15 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Joseph Berry)

[e-mail] (John Gottschalk) writes:

>Submitted-by: [e-mail] (John Gottschalk)

>I am considering using the SUN light-weight process package (a threads library)
>for some software development. I would like to know if there are
>any standards for a threads library, so that the software can be fairly
>portable. Do SVR4 or OSF offer a threads library?

OSF offers a threads library. Furthermore, there is a pthreads "standard"
(not yet approved) POSIX 1003.4a.

Joe Berry
Strategic Software Group, Ltd., 3402 Shelburne Rd, Baltimore, MD 21208
E-mail:  [e-mail]  or  uunet!ssgltd!joe
Phone:  [phone];  Fax: [phone];  Pager: 410-796-6861

Volume-Number: Volume 27, Number 78

From [e-mail]  Tue Apr 14 21:09:18 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11897; Tue, 14 Apr 92 21:09:18 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24130; Tue, 14 Apr 92 21:09:14 -0400
From: Bob Robillard <[e-mail]>
Newsgroups: comp.std.unix
Subject: Mock Ballot on 1003.7.1, POSIX Printing
Message-Id: <[e-mail]>
Organization: UUNET Technologies, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 92 00:05:18 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Robillard)

IEEE P1003.7 POSIX is about to start a "mock ballot" of the
POSIX Print System Requirements.  POSIX is a group of IEEE
sponsored standards defining a UNIX-like operating
environment.  The System Administration Working Group
(1003.7) is the group responsible for system administration
standards (i.e. the type of operations traditionally found
in section 8 of the user manuals--fsck, lpc, mkfs, etc).
The document ready for mock ballot is 1003.7.1, Draft
Standard for Information Technology--Portable Operating
System Interface(POSIX)--System Adminstration
Interface/Printing.

A mock ballot is an unofficial, non-binding version of the
regular ballot procedures.  It is performed to get early
feedback on the direction a standard is taking.  1003.7 has
adopted MIT's Palladium printing system as the base for its
printing standard, and one of the goals of this mock ballot
is to test the acceptability of this choice.

Even if you cannot fully participate in the mock ballot,
1003.7 would greatly appreciate feedback on the choice of
Palladium as the base for this document.  While we would
appreciate extensive comments, a simple yes vote, or a no
vote with an explanation about why Palladium is not an
acceptable base, would be very helpful.

Please fill out the attached form should you wish to join
the mock ballot group.

Martin Kirk
Chair 1003.7


UNIX is a registered trademark of UNIX System Laboratories, Inc.


--------------------------cut here------------------------------

        INVITATION TO JOIN P1003.7 MOCK BALLOT GROUP

The IEEE POSIX P1003.7 System Administration  Working  Group  has
been  developing  the  POSIX  printing inteface, P1003.7.1.  This
standard describes the requirements for printing and printing ad-
ministration.   P1003.7  will  be conducting a mock ballot of the
1003.7.1 starting May 14, 1992 and running until June  30,  1992.
The  purpose of this ballot is to seek feedback on this work from
those interested parties who have been  inside  and  outside  the
development process and to prepare for the formal ballot which is
tentatively scheduled for the second half of 1992.  If  you  pro-
vide  an  E-mail  address,  we will send the draft in Post Script
form via this method.  If you require a hard copy of  the  draft,
we  will  make  every effort to have it in the mail no later than
the start of balloting .  Please indicate your desire to partici-
pate  in  this P1003.7.1 Mock Ballot by sending the following in-
formation:

Name:_____________________________________________________________

E-mail
address:__________________________________________________________

Company/Organization
Name:_____________________________________________________________

Address:__________________________________________________________

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Phone:____________________________________________________________

FAX:______________________________________________________________

My primary interest category relative to this Standard is:
(Check only one)
[ ] General Interest
[ ] User
[ ] Producer

I would like the draft in the following format:
(Check only one)
[ ] Post Script via Email
[ ] Hard copy via U.S. mail

Send this information by Wednesday, April 29, 1992 to:
Bob Robillard                   Voice: 908-699-2249
Bellcore                        FAX:   [phone]
RRC 1D229                       [e-mail]
444 Hoes Lane
Piscataway, New Jersey  08854

Thank you in advance for your consideration of this effort.

Sincerely,
Martin Kirk, Chair IEEE P1003.7













Volume-Number: Volume 27, Number 79

From [e-mail]  Wed Apr 15 16:49:34 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10870; Wed, 15 Apr 92 16:49:34 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06335; Wed, 15 Apr 92 16:49:32 -0400
From: Michael Joosten <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: threads library
Message-Id: <[e-mail]>
Article-I.D.: ftp.si30aINNcgv
References: <[e-mail]>
Reply-To: [e-mail]
Organization: UUNET Communications
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 92 20:17:14 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael Joosten)

In article <[e-mail]>, [e-mail] (Joseph Berry)
writes:
>>I am considering using the SUN light-weight process package (a threads library)
>>for some software development. I would like to know if there are
>>any standards for a threads library, so that the software can be fairly
>>portable. Do SVR4 or OSF offer a threads library?
>OSF offers a threads library. Furthermore, there is a pthreads "standard"
>(not yet approved) POSIX 1003.4a.

The situation concerning threads libraries is currently a bit difficult.
Yes, OSF has POSIX pthread implementation in its DCE package. But it is
unclear how to get only OSF pthreads (which are in reality DEC's CMA (Concert
Multithread Architecture) threads) without all the DCE stuff around. For an
educational site it was rather cheap to join OSF an buy a DCE snapshot (200$ +
1000$), I don't know what they charge now.

Actually , SunSoft has apparently own plans on improving LWP. There is a paper
about this in a recent USENIX (Winter '91 ?) about Sun's further development
plus an interesting paper about how to take care of non-reentrant libraries.

USL? I don't kow, but I would like to hear a bit more about their intentions.
Probably there is something emerging, especially with Chorus and the
much-awaited MultiProcessing Release of SysVR4.

Since currently no vendor actually sells his Unix with a standardized pthreads
AND re-rentrant libraries (except OSF with OSF/1, but that's not a vendor),
the situation is actually a bit hosed: Many developers will face the task to
convert their existing/emerging multithreaded programs to pthreads, and this
could be not always easy. LWP, e.g., offers a yield() function which takes an
explicit LWP argument, thus leading developers to play scheduler-by-their-own
instead of relying on a built-in scheduler or sempahores/mutexes/condition
variables/messages. This nearly happened here, and pthread has of course no
such yield_to(xxx). An explicit yield_to() is fine for coroutines, but does
not make sense for real threads where the scheduler has more kowledge about
which (system) resource is blocked or ready (file descriptors,..) than the
programmer.

Anyway, without re-entrant libs (libc_r.a) there is IMHO not so much profit
with pthreads, since a premptive context change is mostly simulated with
SIGALRM and the finer-grained BSD timer functions. Since most libraries are
not built to cope with changing threads, you either must set 'guards' like
mutexes around a lot of (if not all) C library functions (most of the section
(3) stuff) or be extremly cautiously when coding your system. In the former
case, you will likely lose performance; imagine your program oftenly call libc
functions - every time the mutex has to be locked and released, maybe with an
additional set/reset of the signal mask (expensive system call!).

Well, this is my perspective, now nearly 5-6 months old. If there's something
radically changed, please let me know!

Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120
CADLAB            |       Fax   : (+49) (+) 5251-284 140
Bahnhofstr. 32    |       E-Mail: [e-mail]
D-4790 Paderborn  |                ...!uunet!unido!cadlab!joost
FRG               | Mass mail to: [e-mail]


Volume-Number: Volume 27, Number 80

From [e-mail]  Wed Apr 15 17:49:07 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18696; Wed, 15 Apr 92 17:49:07 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25070; Wed, 15 Apr 92 17:49:04 -0400
From: Chris Flatters <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: threads library
Message-Id: <[e-mail]>
Article-I.D.: ftp.si6vpINNdr3
References: <[e-mail]> [e-mail],
Reply-To: [e-mail]
Organization: NRAO
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 92 21:25:13 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chris Flatters)

In article [e-mail], [e-mail] (Michael Joosten) writes:
>Submitted-by: [e-mail] (Michael Joosten)
>Actually , SunSoft has apparently own plans on improving LWP. There is a paper
>about this in a recent USENIX (Winter '91 ?) about Sun's further development
>plus an interesting paper about how to take care of non-reentrant libraries.

Winter '91 is correct: "SunOS Multi-thread Architecture" by M. L. Powell et al.
I think that it is reprinted in "The SPARC Technology Papers".

The gist of the paper is that Sun have adopted a two-layer model for multi-
threading.  At one level threads are implemented in a user-space library while
at the other light-weight processes are implemented in the kernel.

    Chris Flatters
    [e-mail]


Volume-Number: Volume 27, Number 81

From [e-mail]  Wed Apr 15 17:53:33 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19958; Wed, 15 Apr 92 17:53:33 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26804; Wed, 15 Apr 92 17:53:32 -0400
From: "Kathy A. DeMartini" <[e-mail]>
Newsgroups: comp.std.unix
Subject: pls post comp.std.unix,comp.protocols.pup
Message-Id: <[e-mail]>
Organization: UUNET Communications
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 92 21:46:02 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Kathy A. DeMartini)

I am looking for information concerning Express Technology Protocol
(XTP) or X/Open Transport interface (XTI) with respect to implementation
under Unix. XTP is a 3 level protocol for higher bandwidth versus OSI,
in which TCP/IP or others would be implemented. This is an emerging
standard.

If you could mail me articles or information, it would be appreciated.
Pls e-mail direct versus posting, I will summarize and post whatever
results in 2 weeks.

    Thank you.

Volume-Number: Volume 27, Number 82

From [e-mail]  Sun Apr 19 18:02:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05549; Sun, 19 Apr 92 18:02:00 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22464; Sun, 19 Apr 92 18:01:47 -0400
From: "Robert L. Knighten" <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX P1003.4a (Pthreads) Common Reference Ballot
Message-Id: <[e-mail]>
Reply-To: Bob Knighten <[e-mail]>
Organization: Intel Supercomputer System Division, Beaverton, OR
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 19 Apr 92 21:06:53 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert L. Knighten)

Draft 6 of the P1003.4a (Threads Extension) draft standard is in its second
ballot (first reballot.)  This ballot is due at the IEEE Standards Office on
May 1.

The following group met and drafted a Common Reference Ballot which
we hope will be considered by other members of the ballot group before they
submit their own ballots.  Our CRB is included at the end of this message.

The CRB will be submitted as the first 70 items in the ballot of
Robert L. Knighten of Intel Supercomputer Systems Division.

Nawaf Bitar             Kubota-Pacific
David Black             Open Software Foundation
Bob Conti               Digital Equipment Corporation
Bill Cox                Unix Systems Laboratories
Michael Jones           Carneige-Mellon University
Steve Kleiman           SunSoft
Bob Knighten            Intel Supercomputer Systems Division
Jim Pitcairn-Hill       Open Software Foundation
Dave Plauger            Hewlett-Packard
Paul Rabin              Open Software Foundation

This CRB is also available in various forms (ASCII, postscript, troff) by
anonymous ftp from export.ssd.intel.com in the directory /pub/tmp/CRB.

==============================================================================
Robert L. Knighten  P1003.4a/D6 Ballot 4/3/92
[e-mail]                [phone] FAX [phone]

--------------------------------------------------------------------------
@ all o 1
1: Section all  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ all o 2
2: Section all  page all  line(s) all

OBJECTION:

     The deletion of the POSIX.4 memory model leaves a void in terms of the
     specification of memory access characteristics.  While the CRB group
     is not particularly enamored with the POSIX.4 memory model, we feel
     something is required in this space.

ACTION:

     Specify a memory model for POSIX.4a.  You may contact Nawaf Bitar to
     coordinate assistance in the development of a memory model.

--------------------------------------------------------------------------
@ 2 o 3
3: Section 2  page 2.2  line(s) 4

OBJECTION:

     The term "allocation domain" does not clearly refer to a scheduling
     allocation.

ACTION:

     Change the defined term to "Scheduling Allocation Domain [Allocation
     Domain]".

--------------------------------------------------------------------------
@ 2 o 4
4: Section 2  page 2.2  line(s) 5

OBJECTION:

     The term "contention scope domain" does not clearly refer to a
     scheduling contention scope.

ACTION:

     Change the defined term to "Scheduling Contention Scope [Contention
     Scope]".

--------------------------------------------------------------------------
@ 2.2 o 5
5: Section 2.2  page 5  line(s) 80-81

OBJECTION:

     With the inclusion of the process shared attribute mutexes and other
     synchronization primitives can be used in shared memory by more than
     one processes.

ACTION:

     Delete lines 80-81.

--------------------------------------------------------------------------
@ 2.2 o 6
6: Section 2.2  page 5  line(s) 98-99

OBJECTION:

     The set of synchronous signal that can be generated is not limited to
     the list in the text. For example SIGBUS.

ACTION:

     Either correct the list or change it to the following:
             The signals which may be generaed synchronously include SI-
     GILL,
             SIGFPE, ...

--------------------------------------------------------------------------
@ 2.2 o 7
7: Section 2.2  page 6  line(s) 104

OBJECTION:

     "with a thread" doesn't make sense.

ACTION:

     Change "with a thread" to "by a thread."

--------------------------------------------------------------------------
@ 2.2 o 8
8: Section 2.2  page 6  line(s) 115-116

OBJECTION:

     It should be permissible to use the thread ID of a detached thread if
     the application knows via programmed synchronization that the target
     thread has not exited. Note that a thread cannot spontaneously exit
     without calling pthread_exit(), being cancelled (and running the can-
     cellation handlers), or the process exits.

ACTION:

     Delete the sentence beginning "Detaching a thread also prohibits..."
     or change it to indicate that if the application know via programmed
     synchronization mechanisms that the thread has not exited then using
     the thread ID is permissible.

--------------------------------------------------------------------------
@ 2.2.1.138,6 o 9
9: Section 2.2.1.138,6  page 4,79-101  line(s) 64-65,1-762

OBJECTION:

     The terms global and local contention scope are misleading.  [See ob-
     jection ???.]  The terms system and process contention scope are more
     intuitive.

ACTION:

     Change PTHREAD_SCOPE_GLOBAL to PTHREAD_SCOPE_SYSTEM.  Change
     PTHREAD_SCOPE_LOCAL to PTHREAD_SCOPE_PROCESS.  Change all references
     to `global contention scope' to `system contention scope'.  Change all
     references to `local contention scope' to `process contention scope'.

--------------------------------------------------------------------------
@ 2.2.1.139 o 10
10: Section 2.2.1.139  page 5  line(s) 66-69

OBJECTION:

     The definition of "initial thread" is misleading, and a holdover from
     older drafts with very different semantics.  In particular, calling
     the thread which results from fork() an initial thread is wrong with
     respect to the current usage of the term in the draft.

ACTION:

     Replace the definition of "initial thread" with "The first thread
     which calls main() after an exec, or any thread resulting from a
     fork() by an initial thread".

--------------------------------------------------------------------------
@ 2.6.2 o 11
11: Section 2.6.2  page 14  line(s) 388

OBJECTION:

     The constant name "DATAKEYS_MAX" does not follow the pthreads naming
     conventions.

ACTION:

     Change the name to "PTHREAD_DATAKEYS_MAX".  Similarly, change
     "_POSIX_DATAKEYS_MAX" to "_POSIX_PTHREAD_DATAKEYS_MAX".

--------------------------------------------------------------------------
@ 3 o 12
12: Section 3  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 3 o 13
13: Section 3  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 3.3 o 14
14: Section 3.3  page 29-30  line(s) 408-444

OBJECTION:

     The function pthread_exit() terminates a thread; if you have pthreads
     at all, the fundamental management routines pthread_create(),
     pthread_join, pthread_exit, and pthread_self are essential.  Permit-
     ting any of those functions to be optional in any way means that you
     don't have threads that you can use.  How can an application use the
     fact that pthread_exit() fail?  How can a function that cannot return
     (line 438) "return 01 and set errno to the corresponding value"?

ACTION:

     Delete all error return specification from the pthread_exit() specifi-
     cation.

--------------------------------------------------------------------------
@ 3.3 o 15
15: Section 3.3  page 29-30  line(s) 412-471

OBJECTION:

     The parameter name "status" is misleading.  The actual use of the
     pthread_exit parameter is the return value from the start_function ex-
     ecuted by the thread.

ACTION:

     Change the synopsis to

     void pthread_exit( void *value_ptr);

--------------------------------------------------------------------------
@ 3.3 o 16
16: Section 3.3  page 30  line(s) 431-433,463-471

OBJECTION:

     This return status makes no sense.  The success or failure of a pro-
     cess is not determined by whether the last thread to exit was de-
     tached.  The exit status for the process should be determined by the
     parameter to an explicit _exit() call or the return value to main() as
     specified in POSIX.1.

ACTION:

     Delete lines 431-433 and 463-471.

--------------------------------------------------------------------------
@ 3.3 o 17
17: Section 3.3  page 30  line(s) 459-462

OBJECTION:

     ANSI C does not generally require implementations to preserve integer
     values across multiple typecasts.  The example is non-portable and
     should be deleted.

ACTION:

     Delete text starting at "it is perfectly" and terminate the sentence.

--------------------------------------------------------------------------
@ 3.3.5.2, 7.3.3.2 o 18
18: Section 3.3.5.2, 7.3.3.2  page 29, 105  line(s) 425-427

OBJECTION:

     Talking about main() and exit() under the pthread_exit() is extrane-
     ous.

ACTION:

     Change lines 425-427 to being a note, instead of normative text in the
     pthread_exit() description.  Also, move this text to the description
     of _exit(), in section 7.3.3.2, where it belongs.

--------------------------------------------------------------------------
@ 3.4 o 19
19: Section 3.4  page 37  line(s) 643-652

OBJECTION:

     Measuring overhead in units of the "null loop" is not portable as op-
     timizing compilers can delete null loops entirely.

ACTION:

     Delete this performance metric or restate it in terms of a computation
     that takes a certain amount of time instead of iterations of the null
     loop.

--------------------------------------------------------------------------
@ 3.4 o 20
20: Section 3.4  page 37  line(s) 654-660

OBJECTION:

     Measuring overhead in units of the "null loop" is not portable as op-
     timizing compilers can delete null loops entirely.

ACTION:

     Delete this performance metric or restate it in terms of a computation
     that takes a certain amount of time instead of iterations of the null

     loop.

--------------------------------------------------------------------------
@ 4 o 21
21: Section 4  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 4 o 22
22: Section 4  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 4.4 o 23
23: Section 4.4  page 44-61  line(s) 85-676

OBJECTION:

     There is currently no interface provided by which statically allocated
     mutex and condition variable objects can be statically initialized.
     Providing this ability would make self-initializing modules easier to
     write, and would often make such self-initialization more efficient as
     well.

     Furthermore, there is substantial existing practice which provides
     such interfaces, including Mach cthreads, Encore threads, Sun threads,
     and others.

ACTION:

     Provide new macros PTHREAD_MUTEX_INITIALIZER and
     PTHREAD_COND_INITIALIZER which may be used in static declarations to
     initialize mutexes and condition variables.  The effect of:
         static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
     at compile time should be identical to the effect of:
         static pthread_mutex_t m;
         pthread_mutex_init(&m, NULL);
     at run time.  Similarly, the effect of:
         static pthread_cond_t c = PTHREAD_COND_INITIALIZER;
     at compile time should be identical to the effect of:
         static pthread_cond_t c;
         pthread_cond_init(&c, NULL);
     at run time.

     Also, add rationale similar to the following discussion supporting
     this addition.

     STATIC INITIALIZATION OF SYNCHRONIZATION OBJECTS:

     Providing for static initialization of statically allocated synchroni-
     zation objects  allows modules with private static synchronization
     variables to avoid run time initialization tests and overhead.  Furth-
     ermore, it simplifies the coding of self-initializing modules.  Such
     modules are common in C libraries, where for various reasons the
     design called for self-initialization, instead of requiring an expli-
     cit module initialization function to be called.  An example use of
     static initialization follows.

     Without static initialization, a self-initializing routine foo() might
     look like:
         static pthread_once_t foo_once = PTHREAD_ONCE_INIT;
         static pthread_mutex_t &foo_mutex;
         void foo_init()
         {
             pthread_mutex_init(&foo_mutex, NULL);
         }
         void foo()
         {
             pthread_once(&foo_once, foo_init);
             pthread_mutex_lock(&foo_mutex);
             /* Do work */
             pthread_mutex_unlock(&foo_mutex);
         }
     With static initialization, the same routine could be coded as:
         static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER;
         void foo()
         {
             pthread_mutex_lock(&foo_mutex);
             /* Do work */
             pthread_mutex_unlock(&foo_mutex);
         }
     Note that the static initialization both eliminates the need for the
     initialization test inside pthread_once and the fetch of &foo_mutex to
     learn the address to be passed to pthread_mutex_{lock, unlock}.  Thus,
     the code written is simpler on all machines, and will also be faster
     on a large class of machines.

     Yet people will rightly raise the performance question for machines

     (such as the Sequent Balance) which require mutexes to be allocated
     out of special memory.  Such machines will actually have to have
     mutexes and possibly condition variables contain pointers to the actu-
     al hardware locks.  For static initialization to work on such
     machines, pthread_mutex_lock() will also have to test whether or not
     the pointer to the actual lock has been allocated.  If it hasn't it
     will have to initialize it before use.  This run time test in
     pthread_mutex_lock would at first seem to be extra work.  Yet notice
     that in the above old example, pthread_once() was explicitly called in
     application code for all implementations to test for mutex initializa-
     tion -- in the new example the test is hidden inside
     pthread_mutex_lock() only for those machines which need it.  The over-
     head for machines doing out-of-line mutex allocation is thus similar
     for modules being implicitly initialized, where it's improved for
     those doing mutex allocation entirely inline.   The inline case is
     thus made much faster and the out-of-line case is no worse.

     Two further objections have been raised to static initialization of
     synchronization objects for out-of-line implementations.  First, an
     extra test is required to see if the pointer has been initialized.
     This might seem to add significant expense.  On most machines this
     would actually be implemented as a fetch of the pointer, testing the
     pointer against zero, and then using the pointer if it has already
     been initialized.  While the test might seem to add extra work, the
     extra cost of testing a register is usually negligible since no extra
     memory references are actually done.  As more and more machines pro-
     vide caches, the real expenses are memory references, not instructions
     executed.

     Secondly, it is possible that threads would serialize contending for
     initialization locks when attempting to finish initializing statically
     allocated mutexes.  (Such finishing would typically involve taking an
     internal lock, allocating a structure, storing a pointer to the struc-
     ture in the mutex, and releasing the internal lock.)  First, many im-
     plementations would reduce such serialization by hashing on the mutex
     address.  And second, such serialization can only occur a bounded
     number of times.  In particular, it can happen at most as many times
     as there are statically allocated synchronization objects.  Dynamical-
     ly allocated objects would still be initialized via
     pthread_mutex_init() or pthread_cond_init().  Finally, if this is a
     true issue, static initialization can be avoided altogether by expli-
     citly initializing all synchronization objects with the corresponding
     pthread_*_init() functions.

     In summary:  (1) Static initialization provides a significant simplif-
     ication for programmers of self-initializing modules.  (2) Static ini-
     tialization significantly improves performance for many implementa-
     tions.  (3)  Static initialization will not significantly degrade per-
     formance for any known implementations.  Thus, facilities allowing for
     static initialization of synchronization objects are included as part
     of the threads interface.

--------------------------------------------------------------------------
@ 4.4 o 24
24: Section 4.4  page 48  line(s) 241-251

OBJECTION:

     When a process maps a file that contains a process shared synchroniza-
     tion variable it must not reinitialize it. Similarly, if a process has
     an initialized synchronization variable in MAP_SHARED memory and
     forks, it does not have to be reinitialized.

ACTION:

     After line 251 add something like the following:

     If a process shared mutex has previously been initialized by another
     process, the application shall not reinitialize it.

--------------------------------------------------------------------------
@ 4.4 o 25
25: Section 4.4  page 55  line(s) 477-487

OBJECTION:

     When a process maps a file that contains a process shared synchroniza-
     tion variable it must not reinitialize it. Similarly, if a process has
     an initialized synchronization variable in MAP_SHARED memory and
     forks, it does not have to be reinitialized.

ACTION:

     Add something like the following after line 487:

     If a process shared condition variable has previously been initialized
     by another process, the application shall not reinitialize it.

--------------------------------------------------------------------------
@ 4.4.7.6.1 o 26
26: Section 4.4.7.6.1  page 61  line(s) 681

OBJECTION:


ACTION:

     Change "return successfully" to "return without an error".

--------------------------------------------------------------------------
@ 5 o 27
27: Section 5  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 5 o 28
28: Section 5  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 5.2 o 29
29: Section 5.2  page 73  line(s) 75-80

OBJECTION:

     A standard pthread_key_delete() is needed for dynamically linked li-
     braries to recover storage when they are unlinked. Many modern OS im-
     plementations allow programatic runtime linking in of libraries.

ACTION:

     Add pthread_key_delete(). The destructors should be called in each
     thread.  It is OK if the application id required to ensure that the
     other thread-specific data function are not called simultaneously with
     pthread_key_delete().

--------------------------------------------------------------------------
@ 5.2 o 30
30: Section 5.2  page 74  line(s) 103-107

OBJECTION:

     Destructor functions must be allowed to call functions that can poten-
     tially allocate thread-specific data, otherwise functions must be
     specifically documented as  callable from a destructor or not.

ACTION:

     In order to accomplish this, destructor functions must be called re-
     peatedly until all thread-specific data is destroyed. Lines 158-160
     must also be deleted or modified.

--------------------------------------------------------------------------
@ 5.2 o 31
31: Section 5.2  page 75  line(s) 148

OBJECTION:

     pthread_getspecific() should simply return the value instead of stor-
     ing it through a pointer. This could substantially speed up a critical
     function.

ACTION:

     Change pthread_getspecific to:
             void * pthread_getspecific(pthread_key_t key); If any error is
     detected, NULL is returned.

--------------------------------------------------------------------------
@ 5.2 o 32
32: Section 5.2  page 75-76  line(s) 151-161

OBJECTION:

     Since pthread_{s, g}etspecific may not work if the key is undefined
     the standard should explicitly state that called either of these with
     an uncreated or destroyed key is undefined. This explicitly prevents
     the (erroneous) example in lines 246-255.

ACTION:

     Add something like the following before line 161:
             The effect of calling pthread_getspecific or
     pthread_setspecific
             with a key value that has not been created (or has been des-
     troyed)
             is unspecified.

--------------------------------------------------------------------------
@ 5.2 o 33
33: Section 5.2  page 76  line(s) 174-175

OBJECTION:

     In implementations that support infinite amounts of thread-specific
     data pthread_setspecific can allocate memory and must be able to re-
     turn an error is memory is unavailable.

ACTION:

     Add ENOMEM to the list of errors for pthread_setspecific.

--------------------------------------------------------------------------
@ 5.3 o 34
34: Section 5.3  page 77  line(s) 213-215

OBJECTION:

     The text reads:
             If second and subsequent calls to pthread_setspecific perform
             differently than the first call, then these measurements shall
             also be reported.  In implementation that support an unbounded
     amount of thread-specific data, this can cause an unbounded number of
     measurements.

ACTION:

     Delete this sentence or replace it with measurements of setting
     storage for specified numbers of keys. It is probably best that these
     be less than 32 keys since this is all a strictly conforming applica-
     tion can depend on.

--------------------------------------------------------------------------
@ 5.3 o 35
35: Section 5.3  page 28-29  line(s) 363-407

OBJECTION:

     Since there is a "detached" attribute to thread creation, there is no
     longer very much motivation to include pthread_detach() as a separate
     function. There is very little need to detach a thread on the fly,
     since this is mostly known at thread create time when the thread ID is
     stored.  Making the initial thread be created "undetached" by default
     means that it can be joined with, while the potential storage leak is
     limited.

ACTION:

     Delete pthread_detached(). Add the requirement that the initial thread
     be created "undetached".

--------------------------------------------------------------------------
@ 6 o 36
36: Section 6  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 6 o 37
37: Section 6  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 6 o 38
38: Section 6  page all  line(s) all

OBJECTION:

     The use of realtime-centric nomenclature, and in particular
     SCHED_OTHER, is confusing.  SCHED_OTHER is simply a placeholder for
     "some scheduling algorithm that may be different or not different from
     SCHED_FIFO and SCHED_RR".  This suggests both that SCHED_OTHER is a
     name for some specific scheduling algorithm AND that SCHED_OTHER is a
     name for some selectable scheduling algorithm that may be different
     from SCHED_FIFO and SCHED_RR.

     Unfortunately, SCHED_OTHER can't be both.  The apparent meaning is of
     some system-defined policy that is neither FIFO nor RR.  A more ap-
     propriate name is "SCHED_DEFAULT."

ACTION:

     Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter.

--------------------------------------------------------------------------
@ 6 o 39
39: Section 6  page all  line(s) all

OBJECTION:

     The rationale in this chapter talks about many things, most of which
     are not relevant to the scope of POSIX.4a.  Sections 6.1.1.3 and 6.2.3
     are particularly irrelevant, as they talk about scheduling on a
     machine with allocation domain of size greater than one, which was
     specifically excluded from the scope of scheduling by the working
     group.

     The text of section 6.2.3 is an attempt to extend the semantics of
     uniprocessor scheduling to the multiprocessor domain in a way that ex-
     cludes existing practice or renders the somewhat intuitive SCHED_FIFO
     and SCHED_RR meaningless (line 214-216).  One point made by previous
     POSIX.14 coordination ballots and comments was that priority is less
     meaningful in a multiprocessor.  Line 217 overspecifies behavior.

ACTION:

     Delete this chapter.  Define the interactions of draft POSIX.4
     scheduling behavior and pthreads in a separate document, or move the
     contents of this chapter to a non-normative appendix clearly marked as
     "Uniprocessor Thread Scheduling."

--------------------------------------------------------------------------
@ 6 o 40
40: Section 6  page all  line(s) all

OBJECTION:

     The rationale is excessively broad for the normative text in this
     chapter.  Rationale should explain the derivation and meaning of the
     normative text; the Chapter 6 rationale goes far beyond that.

     The most egregious examples are lines 110-118 (Rate Monotonic Schedul-
     ing) and lines 704-739.  The working group did not accept this text
     even for a non-normative appendix, and including it in this draft or
     any final standard based on this draft is excessive.  The rationale is
     not intended as a place to announce interfaces for "future updates"
     when the working group did not find the interfaces acceptable for in-
     clusion anywhere in the draft.

     The presentation here amounts to an endorsement by POSIX of a research
     effort and related projects by the current technical reviewer and his
     colleagues, and inappropriate to normative or rationale text.

ACTION:

     Delete lines 110-118 and 704-739 and any other references in the draft
     that refer to rate monotonic scheduling or sporadic servers.

--------------------------------------------------------------------------
@ 6 o 41
41: Section 6  page all  line(s) all

OBJECTION:

     This chapter is beyond scope in references to multiprocessors and mul-
     tiprocessor scheduling because the interfaces and uniprocessor tech-
     niques are neither well-understood nor appropriate to multiprocessors.

     The extensions to "scheduling domains of size greater than one" is fa-
     tally flawed because they work either poorly or not at all on current
     and near-future multiprocessor architectures such as the Stanford DASH
     machine.  These interfaces and techniques apply only to uniprocessors,
     therefore they conflict with page 1 lines 25-27, and should be delet-
     ed.

ACTION:

     Delete Chapter 6.

--------------------------------------------------------------------------
@ 6.1 o 42
42: Section 6.1  page 80  line(s) 34

OBJECTION:

     In POSIX, the concept of a "kernel entity" is misplaced.  The proper
     language would refer instead to a "process."

ACTION:

     Change "kernel entity (process)" to "process".

--------------------------------------------------------------------------
@ 6.2.2 o 43
43: Section 6.2.2  page 83  line(s) 186-189

OBJECTION:

     The definition of global contention scope ignores the concept of allo-
     cation domain.  Resource contention only makes sense within an alloca-
     tion domain, as indicated by lines 202-204:         Allocation domain
     is independent of contention scope, as contention         scope merely
     defines the set of threads with which a thread must         contend
     for processor resources, while allocation domain defines         the
     set of processors for which it contends.  The definition of global
     contention scope is inconsistent with this, and makes it impossible
     for systems with multiple allocation domains to support global conten-
     tion scope.

ACTION:

     Rewrite lines 186-189 to read: A thread created with global contention
     scope contends for resources with all other threads in the same allo-
     cation domain relative to their global scheduling attributes.  The
     global scheduling attributes of a thread created with global conten-
     tion scope are the scheduling attributes with which the thread was
     created.  The global scheduling attributes of a thread created with
     local contention scope are the implementation-defined mapping into
     global attribute space of the scheduling attributes with which the
     thread was created.

--------------------------------------------------------------------------
@ 6.2.2 c 44
44: Section 6.2.2  page 84  line(s) 191

EDITORIAL COMMENT:

     Change `which' to `that'.

--------------------------------------------------------------------------
@ 6.2.3 o 45
45: Section 6.2.3  page 84  line(s) 196-219

OBJECTION:

     This section implies that both the allocation domain size and the as-
     signment of threads to allocation domains is static.  Both implica-
     tions can be overly restrictive for some systems.

     The `process control' approach to scheduling (cf. Tucker and Gupta,
     "Process Control and Scheduling Issues for Multiprogrammed Shared
     Memory Multiprocessors", Proceedings of 12th SOSP, December 1989, pp.
     159-166) obtains significant performance advantages from dynamic allo-
     cation domain sizes when it is applicable.

     Non Uniform Memory Access (NUMA) multiprocessors (e.g., BBN Butterfly,
     Stanford DASH) may use a system scheduling structure that involves
     reassignment of threads among allocation domains.  In NUMA machines, a
     natural model of scheduling is to match allocation domains to clusters
     of processors.  Load Balancing in such an environment requires chang-
     ing the allocation domain to which a thread is assigned.  The system
     should have the freedom to do this.

ACTION:

     After line 208, add:         Conforming implementations may change the
     size of allocation         domains and the binding of threads to allo-
     cation domains at         any time. Add the second and third para-
     graphs of the objection text to the Rationale after line 109.

--------------------------------------------------------------------------
@ 6.3 o 46
46: Section 6.3  page 93  line(s) 481-499

OBJECTION:

     The parameter proposed for pthread_yield() is not used and is required
     to be NULL.  The claim in the rationale that this allows extensions is
     bogus.  The use of a void * does not permit passing of any integer or
     long value, hence does not permit the extensibility that is claimed.
     The reference to thread_switch is misplaced in a discussion of a yield
     interface; thread_switch is an implementation tool, not a user-level
     scheduling tool to skirt around the priority scheduling that the rest
     of this chapter says is so important.

ACTION:

     Delete the parameter to pthread_yield and lines 490 and 505-510.

--------------------------------------------------------------------------
@ 6.3 o 47
47: Section 6.3  page 95-96  line(s) 551-590

OBJECTION:

     The priority ceiling "emulation" protocol is slower that priority in-
     heritance in that work must be done in the no-contention case instead
     of the contention case. It is also more difficult to use in that the
     priority of all calling threads must be computed a priori. It is also
     redundant functionality with respect to priority inheritance.

ACTION:

     Delete the priority ceiling "emulation" protocol. Delete
     pthread_mutexattr_setceiling(), pthread_mutexattr_getceiling(), and
     lines 561-587.

--------------------------------------------------------------------------
@ 6.3.4 o 48
48: Section 6.3.4  page 94  line(s) 511-537

OBJECTION:

     The specified behavior for threads with global contention scope
     directly contradicts the requirements of POSIX.4 for processes with
     exactly one thread (namely the initial thread).  This is a fundamental
     conflict between the scheduling primitives in POSIX.4 and POSIX.4a.
     There are two choices here; either resolve the conflict or define it
     out of existence.

     Resolving the conflict is unlikely to yield a clean solution for
     processes that use POSIX.4 scheduling primitives and link against a
     library that creates hidden threads.  The various choices appear to
     be:

     a) Treat the initial thread specially and apply POSIX.4 primitives to
     it alone.

     b) Ensure that a process consisting only of the initial thread is
     treated as POSIX.4 scheduling requires

     c) Extend POSIX.4 scheduling primitives to all threads.

     Option a) is unacceptable because all threads should be as equivalent
     as possible, and compatibility support for POSIX.4 primitives is in-
     sufficient justification for introducing this degree of asymmetry.
     Option c) is also unacceptable because it creates two methods for af-
     fecting the scheduling of threads; this both complicates the implemen-
     tations and makes the resulting program behavior more difficult to
     understand with no benefits.  Option b) is the least objectionable of
     the three, but leaves a POSIX.4 program at the mercy of
     implementation-defined behavior if it should happen to link with a li-
     brary that creates internal threads.  We offer it as one possible
     resolution to this objection with the rationale that an application
     performing its own realtime scheduling must understand the scheduling
     implications of any library that it links to.

     The alternative is to define the problem out of existence by prevent-
     ing the simultaneous use of POSIX.4a primitives and POSIX.4 primi-
     tives.  Doing this at the source level is not straightforward because
     of the ability to link separately compiled modules.  The linker must
     reject any application that attempts to use primitives from both
     classes; dynamically linked libraries complicate this problem.

     Also, the specified behavior for threads with local contention scope
     is an excessively long version of "implementation defined".

ACTION:

     Any of the following actions are acceptable to resolve this objection:

     (1) Replace lines 522-528 with the following:

     The semantics of these functions (except yield()) are exactly as de-
     fined in Priority Scheduling s21, POSIX.4 for processes that consist
     of an initial thread with global contention scope and have created no
     other threads.  In all other cases, the semantics are implementation
     defined.

     (2) Replace lines 522-532 with the following:

     The semantics of these functions are implementation defined.

     (3) Replace lines 522-532 with the following:

     These functions shall fail.

     (4) Delete section 6.3.4 (lines 511-537) and replace it with a res-
     triction that prevents a conforming implementation from defining both
     _POSIX_THREADS and _POSIX_PROCESS_SCHEDULING.  Insert a rationale sec-
     tion explaining how to do this in practice on a system that can sup-
     port each option independently.

--------------------------------------------------------------------------
@ 6.3.4 c 49
49: Section 6.3.4  page 94  line(s) 511-537

EDITORIAL COMMENT:

     POSIX.4 has changed the names of the scheduling functions and symbolic
     constant used in this section.  The new names are prefixed with sched_
     and the new symbolic constant is _POSIX_PRIORITY_SCHEDULING.

ACTION:

     Update to match POSIX.4.

--------------------------------------------------------------------------
@ 6.3 o 50
50: Section 6.3  page 95-96  line(s) 551-590

OBJECTION:

     The priority ceiling "emulation" protocol is slower that priority in-
     heritance in that work must be done in the no-contention case instead

     of the contention case. It is also more difficult to use in that the
     priority of all calling threads must be computed a priori. It is also
     redundant functionality with respect to priority inheritance.

ACTION:

     Delete the priority ceiling "emulation" protocol. Delete:
             pthread_mutexattr_setceiling(),
             pthread_mutexattr_getceiling(),
     and lines 561-587.

--------------------------------------------------------------------------
@ 7 o 51
51: Section 7  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 7 o 52
52: Section 7  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 7.3 o 53
53: Section 7.3  page 104  line(s) 33-56

OBJECTION:

     fork() as defined has only the calling thread continue in the child
     process.  This introduces problems with locks and other state main-

     tained by user code.  For example, if the surviving thread in the
     child blocks attempting to lock a mutex between fork() and exec(), no
     other thread exists to free the lock.  This is exacerbated by limited
     cancelability (cf. Section 9.3.2, page 126) where a blocking
     pthread_mutex_lock operation is not an interruption point, so signals
     and other events that might create another thread cannot do so.

     There are two useful definitions for fork(), one in which only the
     calling thread survives, and a second where all threads in the process
     survive in the child.  With both alternatives useful under some cir-
     cumstances, both should be defined.

ACTION:

     Change the name of fork() on this page to "fork1()".  Define, under an
     option, a new interface, forkall(), defined below, to duplicate all
     extant threads in the child process.  Specify that it is
     implementation-defined whether fork() is fork1() or forkall().

NAME
   forkall()

DESCRIPTION
   forkall() causes creation of a new process, cloning the parent process
   in its entirety including all existing pthreads.

SYNOPSIS
      #include <sys/types.h>
      #include <unistd.h>

      pid_t forkall(void);

PROCESSING
   The new process created by forkall duplicates the calling process, in-
   cluding the set of threads that exist as of the time of the call (up to
   simultaneity constraints), the data area, and stack(s).

OUTPUT
   Upon successful completion, forkall() returns a value of 0 to the new
   process and returns the process ID of the new process to the caller.

ERROR/DIAGNOSTICS
   On failure, a value of (pid_t) -1 is returned to the caller, no new pro-
   cess is created, and errno is set to indicate the error.

      EAGAIN
                The system limit on number of threads per real user-id would be
                exceeded if the call succeeds.

      EINTR
               A forkall() has been interrupted by a forkall() executed by
               another stream of execution in the process.

--------------------------------------------------------------------------
@ 7.3 o 54
54: Section 7.3  page 104  line(s) 33-56

OBJECTION:

     In the event that this ballot's objection with action to define for-
     kall() is accepted, additional rationale is required to address the
     issue of how a portable application would use forkall() and fork1().

--------------------------------------------------------------------------
@ 7.3.1 o 55
55: Section 7.3.1  page 105  line(s)

OBJECTION:

     There are at least two serious problems with the semantics of fork()
     in a multi-threaded program.  One problem has to do with state (e.g.,
     memory) covered by mutexes.  Consider the case where one thread has a
     mutex locked and the state covered by that mutex is inconsistent while
     another thread calls fork(). In the child, the mutex will be in the
     locked state (locked by a non-existent thread and thus can never be
     unlocked).  Having the child simply reinitialize the mutex is unsatis-
     factory since this approach doesn't resolve the question about how to
     correct or otherwise deal with the inconsistent state in the child.

     The Pthreads draft suggests that programs that use fork() will call
     exec() very soon afterwards in the child process, thus resetting all
     state.  In the meantime, only a short list of "safe" library routines
     are promised to be available.

     Unfortunately, this solution does not address the needs of multi-
     threaded libraries.  Application programs may not be aware that a
     multi-threaded library is in use, and will feel free to call any
     number of library routines between fork() and exec(), just as they al-
     ways have.  Indeed, they may be extant single-threaded programs and
     cannot, therefore, be expected to obey new restrictions imposed by the
     thread library.

     On the other hand, the multi-threaded library needs a way to protect
     its internal state during fork() in case it is reentered later in the
     child process.  The problem arises especially in multi-threaded I/O
     libraries, which are almost sure to be invoked between fork() and
     exec() to effect I/O redirection.  The solution may require locking
     mutex variables during fork(), or it may entail simply resetting the
     state in the child after the fork() processing completes.

     pthread_atfork1(), as defined below, provides multi-threaded libraries
     with a mechanism to protect themselves from innocent application pro-
     grams which call fork(), and it provides multi-threaded application
     programs with a standard mechanism for protecting themselves from
     fork() calls in a library routine or the application itself.

     For example, an application can supply a "prepare" routine that ac-
     quires the necessary mutexes the library maintains and "child" and
     "parent" routines that release those mutexes, thus ensuring that the
     child gets a consistent snapshot of the library's state (and that no

     mutexes are left stranded).  Alternatively, some libraries might be
     able to supply just a "child" routine that reinitializes the library's
     mutexes and all associated state to some known value (e.g., what it
     was when the image was originally exec'd).

     Another problem with the semantics of fork() in a multi-threaded pro-
     gram is the question of which threads that exist in the parent are du-
     plicated into the child.  The Pthreads draft states that the child
     process starts with exactly one thread--a copy of the thread that
     called fork(). Unfortunately, in some cases, the right thing would
     have been to recreate at least some of the other threads in the child
     process as well.  pthread_atfork1() allows applications and libraries
     to deal with this problem as well.  A library or application that
     creates threads and wants those threads to exist in the child can sup-
     ply an pthread_atfork1() "child" routine that recreates the threads.
     This is not exactly equivalent to preserving the thread, but it comes
     close and should meet most needs.

ACTION:

     Add the function pthread_atfork1() as specified below.


NAME
   pthread_atfork1() - arrange for fork1 cleanup handling

SYNOPSIS

        pthread_atfork1(void (*prepare)(), void (*parent)(), void
        (*child)());
        void (*prepare)();
        void (*parent)();
        void (*child)();

DESCRIPTION
   pthread_atfork1() declares handlers to be called before and after
   fork1(). The prepare handler is called before fork1() processing com-
   mences.  The parent handler is called after fork1() processing com-
   pletes, but in the parent process. The child handler is called after
   fork1(0 processing completes, but in the child process.

   If no handling is desired at any one of these three places, its
   corresponding handler address may be set to NULL.

   The expected usage is that the prepare handler acquires all mutex locks,
   and the other two handlers release them.

   Alternatively, one may also declare only a child handler to just clear
   any locks.

   The table of fork handlers maintained by pthread_atfork1() should be
   semi-static. That is, it is established by calls to pthread_atfork1()
   during initialization. Handlers are called in last-in, first-out order,
   to enforce any desired locking hierarchy.  Therefore, the order of calls
   to pthread_atfork1() is significant.

RETURN
   pthread_atfork1() returns 0 if successful.  Otherwise, it returns -1 if

   there is insufficient table space to record the handler addresses.

--------------------------------------------------------------------------
@ 8 o 56
56: Section 8  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 8.3.2 o 57
57: Section 8.3.2  page 111  line(s) 142-143

OBJECTION:


ACTION:

     Change these lines to, "POSIX.4a introduces no new async safe func-
     tions."

--------------------------------------------------------------------------
@ 8.3.3.4.1.1 o 58
58: Section 8.3.3.4.1.1  page 113  line(s) 207-215

OBJECTION:

     The interest model no longer applies with the introduction of the new
     signals model.

ACTION:

     Delete these lines.

--------------------------------------------------------------------------
@ 8.4.1.1 o 59
59: Section 8.4.1.1  page 115  line(s) 270

OBJECTION:


ACTION:

     Change to read "int sigwait(const sigset_t *set);"

--------------------------------------------------------------------------
@ 8.4.1.2 o 60
60: Section 8.4.1.2  page 115  line(s) 276

OBJECTION:

     Clarify that it is the caller's responsibility to block signals prior
     to a call to sigwait.

ACTION:

     Change "defined by set shall be blocked" to "defined by set shall have
     been blocked".

--------------------------------------------------------------------------
@ 8.4.1.2 o 61
61: Section 8.4.1.2  page 115  line(s) 274

OBJECTION:

     In the presence of an implementation that supports queued signals it
     should be guaranteed that sigwait doesn't flush all instances of a
     pending signal number.

ACTION:

     After the sentence ending "returns that signal number.", add the sen-
     tence, "If prior to the call to sigwait there are multiple pending in-
     stances of a single signal number, it is implementation-defined wheth-
     er upon successful return there are any remaining pending signals for
     that signal number."

--------------------------------------------------------------------------
@ 8.4.7.4 o 62
62: Section 8.4.7.4  page 121  line(s) 455

OBJECTION:

     ESRCH is a legitimate error return for pthread_kill().

ACTION:

     Add it.

--------------------------------------------------------------------------
@ 9 o 63
63: Section 9  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 9 o 64
64: Section 9  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 9.3.5 o 65
65: Section 9.3.5  page 129  line(s) 225-226

OBJECTION:


ACTION:

     Change these lines to, "POSIX.4a introduces no new interrupt safe
     functions."

--------------------------------------------------------------------------
@ 9.3.4 o 66
66: Section 9.3.4  page 128-129  line(s) 187-217

OBJECTION:

     This is rationale.

ACTION:

     So indicate.

--------------------------------------------------------------------------
@ 10 o 67
67: Section 10  page all  line(s) all

OBJECTION:

     The use of ENOSYS as an error return requires that all implementations
     maintain stubs simply to return an error.  This is silly: the linkage
     editor can easily report that a particular function is not available.

ACTION:

     Eliminate all [ENOSYS] errors in this Chapter.  If the only error is
     ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
     graph as well.

--------------------------------------------------------------------------
@ 10 o 68
68: Section 10  page all  line(s) all

OBJECTION:

     The use of errno is a mistake with new functions.  Existing POSIX.1
     functions and their close relatives should maintain their overall
     structure, as should those tied to existing practice.  The use of
     errno as a global error indicator in multithreaded environments intro-
     duces new difficulties and inefficiencies.

ACTION:

     New functions should not set a global errno, but instead return an er-
     ror indication as the function return value.  The only exception are
     functions such as pthread_exit() which do not return, and
     pthread_self() which cannot fail.  We do not provide synopses for all
     such functions, but will on request from the technical reviewers.

     Change all new functions such as all pthread_ functions to return an
     error indication on failure, as described above.

--------------------------------------------------------------------------
@ 10 c 69
69: Section 10  page all  line(s) all

EDITORIAL COMMENT:

     This chapter needs reorganization.  The ordering of functions and or-
     ganization into major subsections is confusing.

ACTION:

     Reorder and reorganize the chapter, perhaps as a flat list of func-
     tions.

--------------------------------------------------------------------------
@ 10.3.4.2 o 70
70: Section 10.3.4.2  page 155  line(s) 503-504

OBJECTION:

     Given that some input functions can implicitly cause output this re-
     quirement treated strictly can cause deadlocks.  In particular, line
     buffered streams will cause the associated output stream to be flushed
     upon input.

ACTION:

     Add the sentence:  "Implicit operations to streams other than the ex-
     plicitly referenced stream need not behave as if protected by flock-
     file() on such implicitly referenced streams".  Also, add rationale
     saying that this apparent weakening of the semantics is present to
     avoid lock ordering deadlocks.  Mention that line buffered streams can
     cause this problem.
==============================================================================
--
Robert L. Knighten                 | [e-mail]
Intel Supercomputer Systems Division |
15201 N.W. Greenbrier Pkwy.         | [phone]
Beaverton, Oregon  97006         | [phone] [FAX]


Volume-Number: Volume 27, Number 83

From [e-mail]  Fri Apr 24 19:22:53 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27742; Fri, 24 Apr 92 19:22:53 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17649; Fri, 24 Apr 92 19:22:57 -0400
From: Jeffrey Kegler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Hardcopy: I give up
Message-Id: <[e-mail]>
Article-I.D.: ftp.ta427INNrhu
Reply-To: Jeffrey Kegler <[e-mail]>
Organization: Algorists, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 24 Apr 92 23:02:31 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey Kegler)

For those of you who did not read my earlier posting, I laid forth a
pitiful tale of what it involves for an individual to subscribe to the
POSIX documents given the current refusal to provide electronic
access.  It costs me about $1000 and two man-weeks a year in collating
the poorly organized loose leafed material.  This burden has taken
almost all the resources I can afford to devote to POSIX, and leaves
me without the time to actually comment on the materials.

I have decided when the time comes to replenish my deposit to do so
would be counter-productive.  It would only go to perpetuate the
bureaucracy in whose sole interest this bottleneck exists.

Aside from the generation of revenues, the only justification advanced
for the ban on electronic copies is a supposed fear of counterfeits.
I must say "supposed" because there is no evidence of such a concern
in the way the hardcopy is distributed.  The materials are
loose-leafed, pages are numbered variously, or unnumbered, often no
clear indication of which page belongs with which materials is
present, and addenda and hand-written corrections on copies are freely
employed.  If there is a step that could taken to make a
counterfeiter's life easier that may have been omitted, it slips my
mind.

As many in this audience will know, prevention of counterfeits of
electronic copies is relatively easy.  Fresh copies can be obtained
from trusted archives.  Checksumming and other more sophisticated
measures are also possible, if needed.  The RFC's, for example, have
been available in electronic form for a long time, and this method of
distribution has proved very successful.

Electronic access, in fact, makes it easier to prevent and detect
unauthorized alterations, because the pertinent pieces of the document
can be easily be extracted, mailed, and compared.  The argument that
the ban on electronic circulation is based on fear of counterfeiting
fails any examination, and should be seen for the excuse it is.  Can
one take even one month's mailing in hardcopy and verify it character
by character?  Only in electronic form is this possible.

Let me repeat that the issue is not Jeffrey Kegler's access to draft
standards.  This could safely be (in fact, has been) eliminated
entirely with no serious detriment to the process.  The issue is a
dangerous narrowing of the audience for review of the standards, at a
point where the review desperately needs to be widened.

--

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail] or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087

Volume-Number: Volume 27, Number 84

From [e-mail]  Tue Apr 28 16:32:43 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19204; Tue, 28 Apr 92 16:32:43 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09178; Tue, 28 Apr 92 16:32:43 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: POSIX 1003.4a (Pthread) Comments
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 28 Apr 1992 13:27:01 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

  Well, this list has been fairly quiet for a little while, so I
thought I'd send my brief comments on the recent threading specs.  The
format follows that given in Appendix B of the Draft 6 document.

  Please note that I do not speak as a representative of Transarc, but
only on behalf of myself.

Erik Brown            [e-mail]
Transarc Corp            [phone]
The Gulf Tower
Pittsburgh, PA  15206

------------------------------------------------------------------
    Objections to Draft 6 of the POSIX 1003.4a Specification

------------------------------------------------------------------
Erik Brown        [phone]
[e-mail]    FAX: [phone]
------------------------------------------------------------------
@ 4.4 o 1

PROBLEM

  The mutex attributes object may force the pthread_mutex_lock() and
pthread_mutex_unlock() functions to do extra work when a mutex is
acquired or released.  The Process-shared attribute especially may
require extra checking for what should be a very low-level and fast
operation.

  Providing an interface that allows a very fast low-level locking
mechanism will encourage application developers to write code based
solely on the standard.  With the current interface, vendors are
likely to sacrifice portability in the interest of better performance
by attempting to use hardware or OS-specific locking mechanisms where
they are available.  This is especially true if an application does
not interact with other processes and all threads run at the same
priority, which is likely to be a common scenerio.

ACTION

  The pthread_mutexattr_t structure should be removed from the current
mutex interface.

  The mutexattr functionality can be preserved by adding a new type of
locking mechanism with its own attribute object that would allow the
current functionality.  The synchronization protocols and priority
ceilings in Section 6.3 would also be folded into this new mechanism.

------------------------------------------------------------------
@ 4.4 c 2

COMMENT

  It is unfortunate that pthread_mutex_lock() and
pthread_mutex_unlock() are defined to return a value.  On a good RISC
hardware platform with a test-and-set instruction, a lock can be
performed in 2 or 3 instructions in user space, and an unlock in
another 2 or 3 instructions.  Forcing these calls to return an integer
value may add another 1 or 2 instruction to the implementation.

  In addition, the caller is forced to check the return code of these
calls, adding yet another 4 or 5 instructions (to the lock/unlock
pair).  In effect, the cost is almost doubled compared to the same
calls implemented as void functions (assuming no errors).

  If users could be "trusted" not to call these routines incorrectly,
or the working group were willing to allow a segmentation fault as the
only error for an incorrectly called pthread_mutex_lock(), then it
would be nice to see both of these calls as void functions.

------------------------------------------------------------------
@ 4.4 o 3

PROBLEM

  The definition of pthread_mutex_trylock() induces unnecessary
overhead on the caller.  The user must check for -1, and then check
for EBUSY to ensure that -1 was returned because the lock was already
held.

ACTION

  Change the definition of this routine to return a boolean value, or
-1 if a real error occurs.  That is, change lines 330 to 332 as
follows:

    The function pthread_mutex_trylock() returns a positive
    integer if the lock on the mutex object referenced by mutex is
    acquired.  It returns 0 if the mutex is already locked.  If an
    error occurs, it returns -1 and sets errno to indicate the
    error.

------------------------------------------------------------------
@ 5.2 o 4

PROBLEM

  The pthread_getspecific() function in 5.2.2.1 is essentially a
mechanism for providing special thread-specific memory.  This is
likely to be heavily used by threaded applications, so performance of
this function will be critical.  The performance of the current
function is not optimal because the user must examine both the return
code from the function and the value returned in the value parameter.

ACTION

  Change the routine to return the value of the given key, rather than
accepting an address to store the value into.  If the key is invalid,
0 would be returned.  For instance, line 148 would change to be

    void *pthread_getspecific(pthread_key_t key);

------------------------------------------------------------------
@ 6.3 o 5

PROBLEM

  The mutex attributes object may force the pthread_mutex_lock() and
pthread_mutex_unlock() functions to do extra work when a mutex is
acquired or released.  Putting scheduling logic into the low-level
synchronization primitive may be overkill for applications that run
all of its threads with the same priority, or with mutexes that do not
cross thread priority boundaries.

  Providing an interface that allows a very fast low-level locking
mechanism will encourage application developers to write code based
solely on the standard.  With the current interface, vendors are
likely to sacrifice portability in the interest of better performance
by attempting to use hardware or OS-specific locking mechanisms where
they are available.  This is especially true if an application does
not interact with other processes and all threads run at the same
priority, which is likely to be a common scenerio.

ACTION

  While not applying to this section, the pthread_mutexattr_t
structure should be removed from the interface.  A new type of locking
mechanism can provide the synchronization protocols and priority
ceilings in its own attribute object.  These functions should then be
described in terms of this new interface.

------------------------------------------------------------------
@ 8.3 o 6

PROBLEM

  The list of async safe functions in 8.3.2 seems to be incomplete.
In particular, the functions pthread_mutex_unlock() and pthread_self()
should also be asyn safe.

ACTION

  Add these functions to the list given in the final paragraph.

------------------------------------------------------------------
@ 8.4 o 7

PROBLEM

  It seems reasonable that more than one thread in the same process
might be interested in the same signal via the sigwait() function.
Section 8.4.1.2 states that "exactly one of these threads shall return
from sigwait() with the signal number."

  This seems unduly harsh.  For example, various libraries may wish to
clean up from the receipt of a SIGINT, or check for a created child
process (with a polling call to waitpid) when SIGCHLD is received.
Allowing multiple libraries to perform these actions seems worthwhile

ACTION

  Change the second paragraph in Section 8.4.1.2 to read

    If more than one thread is using sigwait() to wait for the
    same signal then all of these threads shall return from
    sigwait() with the signal number.  No order can be assumed in
    the delivery of the signals to the waiting threads.  Also, if
    a thread exits the program after a return from sigwait(), then
    other threads that were also waiting for the signal may not
    actually receive it.

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


Volume-Number: Volume 27, Number 85

From [e-mail]  Fri May  1 21:51:23 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08111; Fri, 1 May 92 21:51:23 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11689; Fri, 1 May 92 21:51:22 -0400
From: Ron Christian <uswnvg![e-mail]>
Newsgroups: comp.std.unix
Subject: Are bugfixes proprietary?
Message-Id: <[e-mail]>
Organization: US West NewVector, Bellevue, WA
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 2 May 92 01:23:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ron Christian)

Recently, in the process of getting a nasty bug fixed, I asked a
computer vendor if this bug fix would be communicated back to the Unix
standards organization from which they got their bits, since the bug
was in the original code.  (Both computer vendor and standards
organization will remain nameless for now.) The vendor's response was
"there is currently no mechanism to communicate bug reports back to
<organization>".  This sounded interesting, so I asked a couple other
vendors if they reported bugs or bugfixes.  I got one "yes" response
and one other "currently no mechanism" response.

Now, this is not by any means a significant sampling of computer
vendors, but it leads me to ask the question in this forum.  Are
vendors who produce an ostensibly standards-based Unix expected to
report bugs back to the standards organization, or is it the general
expectation of the industry that bug fixes are value added by the
vendor and hence proprietary?  Or, is there simply too much overhead
involved in reporting bugs in some reasonably structured fashion?  If
vendors typically don't report bugs, how are standards organizations
(USL, OSF, Posix, X/Open, etc) made aware of them?

I guess I'm interested in how the system is supposed to work, and also
people's observations on how the system works (or doesn't work) in real
life.

Thanks in advance.


                Ron


Volume-Number: Volume 27, Number 86

From [e-mail]  Mon May  4 18:01:55 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17992; Mon, 4 May 92 18:01:55 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02536; Mon, 4 May 92 18:01:52 -0400
From: Matthew Wicks <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Are bugfixes proprietary?
Message-Id: <[e-mail]>
Article-I.D.: ftp.u49s6INNoej
References: <[e-mail]> <[e-mail]>,
Organization: Fermi National Accelerator Laboratory, Batavia IL
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 4 May 92 21:21:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Matthew Wicks)

In article <[e-mail]>, [e-mail] (Ron Christian) writes:
>Are
>vendors who produce an ostensibly standards-based Unix expected to
>report bugs back to the standards organization, or is it the general
>expectation of the industry that bug fixes are value added by the
>vendor and hence proprietary?  Or, is there simply too much overhead
>involved in reporting bugs in some reasonably structured fashion?  If
>vendors typically don't report bugs, how are standards organizations
>(USL, OSF, Posix, X/Open, etc) made aware of them?

It is necessary to differentiate between organizations such as IEEE (POSIX)
and USL or OSF. In the first case, POSIX is just a specification, thus
can't contain a bug of the manner you describe. Now of course the standard
could be poorly specified and thus need changing, but there are official
procedures for that.

On the other hand, USL and OSF license and distribute code and thus should
have some mechanism to allow their customers to report bugs.

--
Matt Wicks
Fermi National Accelerator Laboratory
[e-mail]
708-840-8083

[ Also noted by [e-mail], [e-mail], [e-mail] -- mod ]

Volume-Number: Volume 27, Number 87

From [e-mail]  Wed May  6 15:14:44 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10471; Wed, 6 May 92 15:14:44 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15208; Wed, 6 May 92 15:14:41 -0400
From: "Shane P. McCarron" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Debugging Information Format specification available for review
Keywords: DWARF debug
Message-Id: <[e-mail]>
Article-I.D.: ftp.u99vaINN5k5
Organization: UNIX International
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 6 May 92 18:53:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Shane P. McCarron)

The UNIX International Programming Languages Special Interest Group
has completed a draft of the DWARF debugger format specification, and
is making it available for industry review.  As with all UNIX
International developed specifications, this document is available
for distribution without restriction under an X Window System-like
copyright.

Attached below is the Foreword and Introduction from the document.  If
you would like to receive a copy, send mail to [e-mail]
containing the following:

    path [e-mail]
    send PUBLIC/dwarf.v1.mm

for the troff source, or

    send PUBLIC/dwarf.v1.ps

for the postscript.  If you system supports uncompress and uudecode, you
can request that the data be compressed by placing the command 'compress'
in the message.

If you have any questions about the archive service, please contact
me.  If you have questions about the Programming Languages SIG or the
DWARF specification, please contact the SIG chair, Dan Oldman, at
[e-mail].  If you are interested in participating in the
ongoing discussions of the Programming Languages SIG, please send a
message containing your fully qualified internet address to
[e-mail].

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]



       DWARF Debugging Information Format


       FOREWORD

       This  document  specifies  a  new  generation  of   symbolic
       debugging  information  that  has been developed by the UNIX
       International Programming Languages Special  Interest  Group
       (SIG),  and  is  being  circulated  for industry review.  We
       started  from  the  document  DWARF  Debugging   Information
       Requirements  - Issue 2, dated April 4, 1990, made available
       by AT&T to its source licensees,  and  added  a  significant
       amount  of material to clarify what was originally specified
       and to support additional language constructs that were  not
       in the original specification.

       At  this  point,  the  SIG  believes  that   this   document
       sufficiently  supports  the  debugging  needs of C, C++, and
       FORTRAN 77, and we have released it for public comment.   We
       will  accept  comments on this document until June 15, 1992.
       Comments may be directed via email to me or  posted  to  the
       SIG  mailing list ([e-mail]).  If you are unable to send
       email, paper mail, FAX, or machine readable  copy  on  UNIX,
       MS-DOS, or Macintosh compatible media can be sent to me, and
       I will post it for you.

                           Tony D'Annunzio
                           Vice President of Technology
                           UNIX International
                           Waterview Corporate Center
                           20 Waterview Boulevard
                           Parsippany, NJ 07054
                           Phone:    [phone]
                           Fax: [phone]






















       Revision: 1.0.0            Page 1           January 20, 1992
                          Industry Review Draft








                                          Programming Languages SIG


       1.  INTRODUCTION

       This  document  defines  the  format  for  the   information
       generated  by compilers, assemblers and linkage editors that
       is necessary  for  symbolic,  source-level  debugging.   The
       debugging  information  format  does not favor the design of
       any compiler or debugger.  Instead, the goal is to create  a
       method  of  communicating  an accurate picture of the source
       program to any debugger  in  a  form  that  is  economically
       extensible  to  different languages while retaining backward
       compatibility.

       The design of the  debugging  information  format  is  open-
       ended,   allowing   for   the   addition  of  new  debugging
       information  to  accommodate  new  languages   or   debugger
       capabilities while remaining compatible with other languages
       or different debuggers.

       1.1  Purpose and Scope

       The debugging information format described in this  document
       is  designed  to  meet  the symbolic, source-level debugging
       needs  of  different  languages  in  a  unified  fashion  by
       requiring   language   independent   debugging   information
       whenever possible.  Individual needs, such  as  C++  virtual
       functions  or  Fortran  common  blocks  are  accommodated by
       creating attributes that are used only for those languages.

       This document describes DWARF Version 1, which  is  designed
       to  be binary compatible with the debugging information that
       is described in the  document  DWARF  Debugging  Information
       Requirements  -  Issue  2,  dated  April  4,  1990, and made
       available by AT&T to its  source  licencess.  The  April  4,
       1990,  document  describes the debugging information that is
       generated by the UNIX System V  Release  4  C  compiler  and
       consumed by the System V Release 4 debugger, sdb.

       By ``binary compatibility'' we mean that

         1.  All  features  intended  to  support  C  and   Fortran
             described  in the April 4, 1990, document are included
             in this document, and

         2.  DWARF produced according to  this  (DWARF  Version  1)
             specification  should  be  considered well formed by a
             System V Release 4 compatible DWARF consumer,  but may
             contain  information that such a consumer is unable to
             interpret.  Consumers  are  expected  to  ignore  such
             information.




       Revision: 1.0.0            Page 3           January 20, 1992
                          Industry Review Draft








       DWARF Debugging Information Format


       The intended audience for this document are  the  developers
       of  both  producers  and consumers of debugging information,
       typically language compilers, debuggers and other tools that
       need  to interpret a binary program in terms of its original
       source.

       This version of the document is a draft for industry review.
       Vendors  developing  products  based on this draft should be
       aware that the review process may produce changes.

       1.2  Overview

       There are two major pieces to the description of  the  DWARF
       format  in  this document.  The first piece is the debugging
       information, itself.   Section  two  describes  the  overall
       structure  of that information.  Section three describes the
       specific  debugging  information  entries   and   how   they
       communicate  the  necessary  information  about  the  source
       program to a debugger.

       The second piece of the DWARF description  is  the  way  the
       debugging  information  is  encoded  and  represented  in an
       object file.  The DWARF encoding  is  presented  in  section
       four.

       Section five  describes  compatibility  constraints  on  the
       format.     Finally,    section   six   describes   external
       dependencies.

       In the following sections, text  in  normal  font  describes
       required  aspects  of  the DWARF format.  Text in italics is
       explanatory or supplementary material, and not part  of  the
       format definition itself.

       1.3  Vendor Extensibility

       This document describes only the features of DWARF that have
       been  implemented  and tested by at least one vendor (with a
       very few exceptions).  It does  not  attempt  to  cover  all
       languages  or even to cover all of the interesting debugging
       information needs for its primary target languages (C,  C++,
       Fortran).   Therefore the document provides vendors a way to
       define their own  debugging  information  tags,  attributes,
       fundamental   types,  type  modifiers,  location  atoms  and
       language names, by reserving a portion of the name space and
       valid  values  for  these  constructs  for  vendor  specific
       additions.  Future versions of this document  will  not  use
       names or values reserved for vendor specific additions.  All
       names and values not reserved for vendor additions, however,
       are  reserved  for  future  versions  of this document.  See
       section 4 for details.


       Revision: 1.0.0            Page 4           January 20, 1992
                          Industry Review Draft
--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]

[ I wasn't sure about allowing this here.  Please let me know whether
 or not you, the readers, want information like this posted  -- mod ]

Volume-Number: Volume 27, Number 88

From [e-mail]  Fri May  8 14:15:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11018; Fri, 8 May 92 14:15:12 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21489; Fri, 8 May 92 14:15:16 -0400
From: Bob Robillard <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX 1003.1/1003.16 (Language Independent POSIX Ballot extended)
Organization: UUNET Communications
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 8 May 1992 10:19:24 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Robillard)

The deadline for getting in the ballot group for POSIX
1003.1/1003.16 has been extended to May 15.  This is the
"Language Independent" version and "C binding" of the
POSIX system calls.  If you care about the way that all
future POSIX APIs will be written I suggest you ballot
this draft.

The sign-up form IEE sent out says to contact IEEE's Anna
Kaczmarek at 908-562-1571 to get involved with this.
(Don't get in touch with me; I'm just a civilian about
this...)

For people unfamiliar with POSIX's new "Language Independent"
movement, here's my heavily biased take:  Bew POSIX APIs
will not be C language APIs.  They have to be written in
new, invented programming language that is supposed to be
easily translatable to Ada, or Fortran, or even C.  API's
written in this new, invented programming language are called
"Language Independent APIs."

Each "Language Independent APIs" should come with translations
to real programming languages (like C, Ada and Fortran).  These
translations are called "bindings."  In order to find out what
a given function is supposed to do, you'll need to read the
Language Independent Spec to find out the basic functionality,
and then read the language binding to find out the syntax and
language specific functionality.

Bob Robillard, Technical Editor, 1003.7      Bellcore
[e-mail]                         RRC 1D-229
bcr!cupid!duke                               444 Hoes Lane
908-699-2249, FAX: [phone]              Piscataway, NJ 08854



Volume-Number: Volume 27, Number 89

From [e-mail]  Fri May  8 22:27:27 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04446; Fri, 8 May 92 22:27:27 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05278; Fri, 8 May 92 22:27:34 -0400
From: James Buster <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix.1 oddity: why specify this?
Message-Id: <[e-mail]>
Organization: Lynx Real-Time Systems, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 May 92 01:52:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (James Buster)

Moderator!:  Delete most of these lines (begin):

In IEEE Posix Std. 1003.1 (ISO/IEC 9945-1) states, under the definition
of utime() (Pages 108-110):

    "If the _times_ argument is not NULL, it is interpreted as a
    pointer to a utimbuf structure, and the access and modification
    times are set to the values contained in the designated structure.
    Only the owner of the file and processes with appropriate
    privileges shall be permitted to use the utime() function in
    this way."

Later, in the Errors section:

[EPERM]    The _times_ argument is not NULL, the effective user ID of the
    calling process has write access to the file, but does not
    match the owner of the file, and the calling process does not
    have the appropriate privileges.

Here is my question: Why mention write access in the EPERM description?
Clearly, as described above, if _times_ isn't NULL, write access is not
considered when determining whether to grant a successful call to utime().
I can only conclude that mentioning write access is an error on the part
of the drafters of this document. Any Posix experts care to comment?
--
                James Buster
                 [e-mail]


Volume-Number: Volume 27, Number 90

From [e-mail]  Wed May 13 15:45:59 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04688; Wed, 13 May 92 15:45:59 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07219; Wed, 13 May 92 15:46:02 -0400
From: Brian Button <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX binary semaphore question
Organization: Western Geophysical Exploration Products
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 13 May 1992 12:38:42 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Brian Button)

Is there a way to find out the control information regarding POSIX.4
binary semaphores? I need a way to find out the uid and gid of the
creator and the size of the semaphore set which was created.

Any suggestions?
--
Brian Button          | email : [e-mail], [e-mail]
Design Engineer       | voice : [phone]
Western Geophysical
3600 Briarpark
Houston, Texas  77042

Volume-Number: Volume 27, Number 93

From [e-mail]  Wed May 13 15:48:29 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04825; Wed, 13 May 92 15:48:29 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07902; Wed, 13 May 92 15:48:33 -0400
From: Ian Lance Taylor <[e-mail]>
Newsgroups: comp.std.unix
Subject: UUCP standardization effort
Message-Id: <[e-mail]>
Article-I.D.: ftp.urqs9INNagg
Organization: UUNET Communications
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 13 May 92 19:32:25 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ian Lance Taylor)

I recently discovered that the UUCP program suite is apparently being
considered for standardization by the POSIX networking interfaces
group.  Is the group actively meeting, and, if so, is there any way to
get in touch with the relevant people via e-mail?

Thanks, and apologies if this is well-known information.
--
Ian Lance Taylor                [e-mail]                uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``They were all-but forgotten people: the breed that was remembered with a
  start, or with the unreality of a recrudescent dream.''


Volume-Number: Volume 27, Number 91

From [e-mail]  Wed May 13 15:48:37 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04833; Wed, 13 May 92 15:48:37 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07927; Wed, 13 May 92 15:48:41 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Anyone heard of PICK???
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: Materials Research Lab
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 13 May 92 19:34:03 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

I have heard of something called PICK, which, from what little I've heard,
seems to be some sort of user-friendly, business-application-oriented
shell which runs on top of Unix.

It sounds like this is something standard.

I know there are books about PICK, but can anyone provide me with some
on-line sources of information, etc. --- such as anonymous-ftp
sites for PICK utilities and so forth?

Many thanks!


Volume-Number: Volume 27, Number 92

From [e-mail]  Thu May 14 14:51:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16090; Thu, 14 May 92 14:51:50 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19742; Thu, 14 May 92 14:51:54 -0400
From: Malcolm Stayner <[e-mail]>
Newsgroups: comp.std.unix
Subject: COMMA SEPARATED VALUE FILES
Organization: Office Support Centre, Fujitsu ICL (NZ) Ltd, Wellington, New Zealand
Message-Id: <[e-mail]>
Reply-To: Malcolm Stayner <usenet![e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: CSV,standards
X-Submissions: [e-mail]
Date: 14 May 1992 11:40:45 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Malcolm Stayner)

I've recently come across a situation where a UNIX application incorrectly
processed a CSV file because null fields were not delimited by double quotes.
e.g.
    Apple,Banana,,,Orange

instead of:

    Apple,Banana,"","",Orange

Does anyone know of a formal standard for CSV files and, in particular the
correct rules for the above situation?

--
Malcolm Stayner           Email: [e-mail]  "Intelligence is silence,
Open Systems Consultant   Tel: [phone]       truth is being invisible,
Fujitsu ICL N.Z. Ltd      Fax: [phone]       but what a racket I make in
P.O. Box 394, Wellington, New Zealand               declaring this" NED ROREM


Volume-Number: Volume 27, Number 94

From [e-mail]  Thu May 14 16:47:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23998; Thu, 14 May 92 16:47:47 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19953; Thu, 14 May 92 16:47:52 -0400
From: Chris Wagner <[e-mail]>
Newsgroups: comp.std.unix
Subject: Feature Test macros for POSIX
Organization: Silicon Graphics, Research & Development
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 14 May 1992 12:57:26 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chris Wagner)

I am trying to figure out the feature test macro for POSIX1003.4 and 4a.
Although draft 12 gives lots of compile-time option constants, it seems
to imply that the only feature test macro is _POSIX_C_SOURCE.
Draft12 seems to imply that as of a certain date (the date of approval
I assume) all the symbols defined in POSIX1003.4 will suddenly be
added to header files such as stdio.h, etc. A user can optionally
set _POSIX_C_SOURCE to an earlier date to preclude certain symbols.
Is this right?? It seems kind of silly to base visibility on date.
I would expect that most  developers will still want to be able
to demand a pure 1003.1 symbol environment.
Is this _POSIX_C_SOURCE just a 1003.4 hack? or has it been
formally adopted at the way the future POSIX stds will
be added to existing headers.

It seems to me that each standard should add feature test macros that
can be defined at compile time...(e.g. _POSIX_4SOURCE, etc.)

----
Chris Wagner ([e-mail])

Volume-Number: Volume 27, Number 95

From [e-mail]  Sat May 16 21:03:38 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00650; Sat, 16 May 92 21:03:38 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18974; Sat, 16 May 92 21:03:44 -0400
From: David A Willcox <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Feature Test macros for POSIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 May 92 19:26:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (Chris Wagner) writes:

>I am trying to figure out the feature test macro for POSIX1003.4 and 4a.
>Although draft 12 gives lots of compile-time option constants, it seems
>to imply that the only feature test macro is _POSIX_C_SOURCE.
>Draft12 seems to imply that as of a certain date (the date of approval
>I assume) all the symbols defined in POSIX1003.4 will suddenly be
>added to header files such as stdio.h, etc. A user can optionally
>set _POSIX_C_SOURCE to an earlier date to preclude certain symbols.
>Is this right?? It seems kind of silly to base visibility on date.
>I would expect that most  developers will still want to be able
>to demand a pure 1003.1 symbol environment.
>Is this _POSIX_C_SOURCE just a 1003.4 hack? or has it been
>formally adopted at the way the future POSIX stds will
>be added to existing headers.

A short tutorial on POSIX feature test macros ...

OK, here's the the way it works.  An ANSI C compiler is not allowed to
make symbols visible to an application beyond what's defined in ANSI
C, unless the application does something explicit to make those
symbols available.  The application does this by defining one or more
feature test macros before including any headers.  Basically, if the
application defines a feature test macro, it is saying that it "knows"
about, and is willing to deal with, the additions to the name space
that are associated with that feature test macro.

_POSIX_C_SOURCE is the new POSIX method for controling visibility of
POSIX symbols.  The application sets _POSIX_C_SOURCE to a date value,
and that PERMITS the implementation to make visible any symbols
associated with parts of POSIX that were approved on or before that
date.  (Using a date as the value is arbitrary.  A simple integer that
was incremented with each new revision could have been used, but we
felt that a date would be more meaningful to humans.)  The
implementation then informs the application which options it actually
supports through version macros (e.g. _POSIX_VERSION and
_POSIX2_C_VERSION), or specific "feature present" macros (e.g.
_POSIX_SYNCHRONIZED_IO).

So, if an application only wants to see only POSIX.1 ("POSIX Classic"),
then it will define _POSIX_SOURCE.  Only symbols defined in IEEE
Std 1003.1-1990 (or -1988) will appear, even if the implementation
supports POSIX.2, POSIX.4, and ten other options that haven't been
created, yet.  An application that needs POSIX.1 and POSIX.2 Annex B
will define _POSIX_C_SOURCE to 199208L [exact value not yet
determined], and POSIX.4 symbols will not appear.  An application that
wants only POSIX.4 will define _POSIX_C_SOURCE to 199209L [again,
exact value not yet determined], and the implementation is then
permitted to make visible symbols from POSIX.1, POSIX.2, and POSIX.4.

A couple of things to note:
(1) Just because the application sets _POSIX_C_SOURCE to a value, does
    not mean that the imlementation supports all of the requested
    options.  If the application sets _POSIX_C_SOURCE to 199209L
    [using the above example] but the implementation doesn't support
    POSIX.4, then clearly POSIX.4 symbols might or might not appear.
(2) There is no way for an application to say "I want POSIX.4 symbols
    but NOT POSIX.1 or POSIX.2 symbols.  It doesn't need to use the
    unwanted options, but it must respect the reserved namespace of all
    options defined before
(3) It is our hope that the IEEE will publish a table saying "here are
    the symbols defined if <header.h> is included and _POSIX_C_SOURCE
    is set to yyyymmL" whenever a new revision is approved.
(4) If this was all consistent, defining _POSIX_C_SOURCE as 199009L
    would be equivalent to defining _POSIX_SOURCE.  Unfortunately,
    that isn't required by the current version of POSIX.1.

>It seems to me that each standard should add feature test macros that
>can be defined at compile time...(e.g. _POSIX_4SOURCE, etc.)

The feature test macros are defined at compile time, it's just that
there is only one feature test macro instead of many.

Something that many people don't understand is that the different
POSIX.* docuements are not different standards.  POSIX.2 Annex B,
POSIX.4, POSIX.4a, POSIX.1a, plus several others, are revisions of
POSIX.1 describing optional features.  Ultimately, they are all
considered part of one ISO standard, 9945-1.  (Somebody will probably
correct me on this, but 9945-2 is shell and utilities [most of POSIX.2],
and 9945-3 is system administration.) So it actually makes more sense
for all of the C bindings to use the same feature test macro than to
give each option of the standard its own feature test macro.

David A. Willcox        "Just say 'NO' to universal drug testing"
Motorola MCG - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534


Volume-Number: Volume 27, Number 96

From [e-mail]  Sat May 16 21:03:44 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00657; Sat, 16 May 92 21:03:44 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18985; Sat, 16 May 92 21:03:51 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Anyone heard of PICK???
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 May 1992 12:27:15 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

>Submitted-by: [e-mail]
>I know there are books about PICK, but can anyone provide me with some
>on-line sources of information, etc. --- such as anonymous-ftp
>sites for PICK utilities and so forth?

Unless things have changed since I last encountered it, PICK is a proprietary
product of one particular company, and you will have to talk to them about
machine-readable documentation, utilities, etc.

It used to be a complete operating system, in fact.  They eventually saw
which way the wind was blowing and did a port to the Unix environment.
--
ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
Networking                              |  [e-mail]  utzoo!henry


Volume-Number: Volume 27, Number 97

From [e-mail]  Mon May 18 23:06:48 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16231; Mon, 18 May 92 23:06:48 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26475; Mon, 18 May 92 23:06:53 -0400
From: Bob Larson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Anyone heard of PICK???
Organization: USC Software Systems, home of TOADS
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 May 1992 12:10:04 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Larson)

Pick is a data-base and operating enviornment (including programming
language) designed around the commands used to query the data-base.
It's main strength is the ability to quickly design new reports.

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>>Submitted-by: [e-mail]
>>I know there are books about PICK, but can anyone provide me with some
>>on-line sources of information, etc. --- such as anonymous-ftp
>>sites for PICK utilities and so forth?
>
>Unless things have changed since I last encountered it, PICK is a proprietary
>product of one particular company,

Technicly true, although that is also true of Unix.  However, the
(proprietary to other companies) work-betters have been around for
well over a decade.  (Unlike Unix, where no-AT&T code work-alikes are
relitivly recent.)  There are at least four competing variations
running on various Unix platforms, (Universe, Unidata, Prime
Information/Open, and Advanced Pick) as well as those running on other
operating systems and stand alone.

>and you will have to talk to them about
>machine-readable documentation, utilities, etc.

There are several magizines devoted to Pick-Alikes, and various
user-groups and trade shows.  Quite a few companies make their living
selling utilities and doing consulting on Pick systems.

I don't know of any FTP sites.  Comp.sys.prime sometimes has
discussions of Prime Information and Prime Information/Open.

>It used to be a complete operating system, in fact.

And still is.  Although cheap Unix boxes are making it less common.

>They eventually saw
>which way the wind was blowing and did a port to the Unix environment.

After noting lost sales to compeditors.

Disclaimer: I work for a company that sells a utility for building
data entry screens for three of the four above mentioned Pick-based
eviornments, and sells one of them.  (And even Unix boxes to run it
on, if you want.)  Call [phone] and ask for someone in sales
if you are interested.


Volume-Number: Volume 27, Number 98

From [e-mail]  Mon May 18 23:06:56 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16237; Mon, 18 May 92 23:06:56 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26498; Mon, 18 May 92 23:07:03 -0400
From: Al Bledsoe <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Anyone heard of PICK???
Organization: sdf Public Access UNIX, Dallas--unrestricted free shell access
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 May 1992 12:10:30 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Al Bledsoe)

>>I know there are books about PICK, but can anyone provide me with some
>>on-line sources of information, etc. --- such as anonymous-ftp
>
>It used to be a complete operating system, in fact.  They eventually saw

PICK has been ported to UNIX for awhile now.  UniVerse by Vmark and
Unidata are serious implementations.  It is a DBMS that is relational
but not Codd relational.  Read BYTE of May 1992, "Two Steps Forward
and One Step Back".  PICK is similar to MUMPS in that it has existed in
vertical niche markets.  But even though PICK is not ANSI like MUMPS
the InfoBASIC language and file structure make it quite a serious
contender in real world development cycles.  Unidata provides a SQL
frontend and UniVerse's release 7 will have SQL.  I'm from a MUMPS
background doing migration from PICK to Informix.  The transactional
section of the package will be left in PICK and the analytical in
Informix Wingz.

PICK and MUMPS kick RDBMS's to pieces in performance,  with SQL their
once closed nature will be open,  shoot,  running on most open
systems now, without SQL maybe they're open already... read the BYTE
article.
---
[e-mail]

Volume-Number: Volume 27, Number 99

From [e-mail]  Mon May 18 23:07:02 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16245; Mon, 18 May 92 23:07:02 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26536; Mon, 18 May 92 23:07:09 -0400
From: David A Willcox <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Feature Test macros for POSIX
Message-Id: <[e-mail]>
Article-I.D.: ftp.v8vg1INNn64
References: <[e-mail]> <[e-mail]>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 May 92 19:10:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (David A Willcox) writes:

Just to keep the record straight...

>                                         ...  POSIX.2 Annex B,
>POSIX.4, POSIX.4a, POSIX.1a, plus several others, are revisions of
>POSIX.1 describing optional features.  Ultimately, they are all
>considered part of one ISO standard, 9945-1.  ...

POSIX.2, Annex B, though it does contain C functions, is not currently
part of 9945-1, but rather 9945-2.  However, there is a proposal on
the floor to move that part of POSIX.2 into POSIX.1 and POSIX.16.
(The C interfaces would go into POSIX.16.  The not-yet-written
language-independent versions would go into POSIX.1.)  As I understand
it (don't take my word for this), those C functions would then become
part of 9945-1.


Volume-Number: Volume 27, Number 100

From [e-mail]  Mon May 18 23:07:08 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16252; Mon, 18 May 92 23:07:08 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26550; Mon, 18 May 92 23:07:16 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Feature Test macros for POSIX
Message-Id: <[e-mail]>
Article-I.D.: ftp.v8vhlINNn7h
References: <[e-mail]> <[e-mail]>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 May 92 19:11:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (David A Willcox) writes:
>OK, here's the the way it works.  An ANSI C compiler is not allowed to
>make symbols visible to an application beyond what's defined in ANSI
>C, unless the application does something explicit to make those
>symbols available.  The application does this by defining one or more
>feature test macros before including any headers.

More accurately:  In order to conform to the C standard, a C implementation
must, among other requirements, accept any strictly conforming C program.
A strictly conforming C program must, among other requirements, not use
certain classes of identifiers in contexts where they have been reserved
for use by C implementations.  And a conforming C implementation must not
define any identifiers in the standard headers other than those specified
in the standard plus those reserved for implementations.  (Reserved
identifiers mostly begin with underscore; see the C standard for details.)

There are no requirements on any headers other than those specified in the
standard; thus additional facilities can AND SHOULD be defined by separate
headers, not through modifications to the standard headers.  This is
especially important when the standard C implementation is provided by
one source of supply but the additional functionality is provided by a
different source of supply, as frequently ocurs in this industry.

The only reason there was any need for "feature flags" in the first place
was the historical accident that some of the standard headers (notably
<stdio.h>) included interface definitions for UNIX-specific facilities AND
general portably-available facilities.  The C standard does not single out
the UNIX environment for an exception, but rather prohibits pollution of
the identifier name spaces by ANY conforming implementation.  Thus, for
<stdio.h> and a few other standard headers, a conforming C implementation
can make additional non-reserved symbols (such as "popen") visible ONLY to
programs that are NOT strictly conforming.  The method chosen by 1003.1 for
this was for the program to somehow #define _POSIX_SOURCE before including
the relevant standard header.  This allows the implementation to key on
that symbol to "turn on" additional symbols in the standard header, without
those symbols being visible in the absence of such a feature flag.

As the last acting liaison between X3J11 and P1003, I was heavily involved
in getting this issue resolved.  1003.1 did not quite follow X3J11's
recommendations, apparently adopting a different view of feature flags,
and from what David has said I gather that the repeated message from X3J11
to 1003 to not further pollute the standard headers has gotten lost.

For NEW facilities (i.e. not those inherited from historic implementations
of UNIX), use new, distinct headers for defining new interfaces; don't add
new symbols (whether or not under control of feature flags) to standard C
headers.  Please!


Volume-Number: Volume 27, Number 101