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

Internet Message Format | 1990-08-02 | 576KB

From [e-mail]  Fri May 18 13:47:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17969; Fri, 18 May 90 13:47:32 -0400
Posted-Date: 18 May 90 17:12:59 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA08026; Fri, 18 May 90 12:47:19 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07994; Fri, 18 May 90 12:14:16 cdt
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 20
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 May 90 17:12:59 GMT
Apparently-To: [e-mail]

From: John S. Quarterman <[e-mail]>

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

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 X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    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,
    the UniForum Technical Committee,
    the USENIX Standards Watchdog Committee.

Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is John S. Quarterman, who is also the
Standards Liaison for the USENIX Association.

Disclaimer.

Postings by any committee member (especially including me) 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.

* 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.


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

The hostname cs.utexas.edu may be used in place of uunet.uu.net or uunet.
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, longway.tic.com,
cs.utexas.edu, or usenix.org.  There are also occasional guest moderators,
who may post from still other machines.  Guest moderators are announced
in advance by the regular moderator.

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/comp.std.unix/archive
or
        ~ftp/comp.std.unix/volume.19
The previous volume may be retrieved as
        ~ftp/comp.std.unix/volume.18.Z

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/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/comp.std.unix; ls -l" is in
        ~ftp/comp.std.unix/list
and the output of "cd ~ftp/comp.std.unix; ls -l *" is in
        ~ftp/comp.std.unix/longlist

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


General submission acceptance policy.

I post more than 90% of all submissions.  However, as moderator,
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.  Very
occasionally I reject an article outright:  this is almost always
because it contains ad hominem attacks, which are never permitted.

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 with multiple newsgroups indicated
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.

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.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address, 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 IEEE 1003, IEEE 1201, X3J11,
or 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 19, Number 200
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.



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.

Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I always 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.

Excess white space is deleted.

Lines longer than 80 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



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 approximately 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
Jeff Haemer <[e-mail]>.  Reports on other committees, such as
X3J11, are also included when available.  These reports are reviewed
for publication by John S. Quarterman acting as publisher for the
USENIX Standards Policy Committee, which consists of Quarterman (chair),
Marshall Kirk McKusick (USENIX President), Alan G. Nemeth (past USENIX
President), and Ellie Young (USENIX Executive Director).  The 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 reviewed by John S. Quarterman, USENIX
Standards Liaison, acting as manager of the ISO Monitor Project.  They
are published in the EUUG Newsletter (EUUGN), :login;, and comp.std.unix.
They are also available for publication elsewhere.

John S. Quarterman, moderator, comp.std.unix and [e-mail].

Volume-Number: Volume 20, Number 1

From [e-mail]  Sat May 19 14:24:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12671; Sat, 19 May 90 14:24:16 -0400
Posted-Date: 18 May 90 21:10:49 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA04198; Sat, 19 May 90 13:24:13 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA10450; Sat, 19 May 90 10:11:09 cdt
From: Peter da Silva <ficc.ferranti.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 18 May 90 21:10:49 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

I find myself in violent agreement with most of the points raised here,
but there are two areas I don't think have been adequately thought through,
and I have one alternative suggestion.

(mmap):
> SVID 3 (System V Release 4.0), OSF AES (OSF/1), Berkeley BSD 4.4, MACH
> 2.5, ULTRIX, SunOS, HP/UX, etc, all include an (almost) identical
> definition of mmap() based on the current Sun/Berkeley specification.

V.3.2 does not include this interface, and V.3.2 is going to be around,
and in fact very common, for at least a couple of years to come. A standard
that locks out V.3.2 is going to hurt portability.

I believe that implementing shared memory in terms of memory mapped files
is a good thing, and that every effort should be made to encourage it...
within reason. Preventing the implementation of POSIX shared memory on
the largest installed base of UNIX systems in existence is not within
reason.

If the interface is "mmap" with a set of constant parameters, this will
serve to hurt portability.

    a) People with "real mmap" will end up using more than the
       standard allows. This is a pretty simple prediction... look
       at existing extended implementations.

    b) People with the "fake mmap" will end up blowing the extra
       parameters, "safely". Then when run on a system with the real
       thing their programs will fail.

In practice, it would be best for both interfaces to (for portable
programs, anyway) have a #define that hides the extra parameters. Which
is exactly what the draft does.

(IPC in general):
I don't believe the interface requires a shared file system. "mkmq()"
can broadcast a message to all machines to create the named file as a
normal file and place in it a special token. This token can be read from
the file descriptor returned by "open()", and used by the "mq*()" routines
to indicate the real name of the message queue.

I think it fairly important to put as many of the names of objects in the
UNIX file system name space as possible. See pp 256,257.

And one minor point (a wish-list entry):

(sender_t in IPC):
> The only information about the sender which would be useful
> would be an indication about how to reply to the sender.  In
> this framework that would be a pathname;

Or a file descriptor, perhaps? I had some questions about the utility of
this feild, too, since it can't be used for any portable purpose. I'd rather
see some meaning defined for it, though, than have it kicked out. Since
returning an fd here is probably not a portable usage, this is a bit of a
wish-list item...
--
`-_-' Peter da Silva. [phone].  <[e-mail]>
 'U`  Have you hugged your wolf today?  <[e-mail]>
@FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.

Volume-Number: Volume 20, Number 2

From [e-mail]  Sat May 19 15:44:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28102; Sat, 19 May 90 15:44:08 -0400
Posted-Date: 19 May 90 19:18:00 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA06935; Sat, 19 May 90 14:44:04 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA10960; Sat, 19 May 90 14:19:07 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 May 90 19:18:00 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide

Kevin Lewis <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Where we are

The Utah meeting of the IEEE 1003.0 working group marks the beginning
of its third year.  Let's step back for a moment to review the past
two.  We have gone from scratch to a 180-page document, whose content
represents about 70% of the content goal that we set for our work two
years ago.  (More on this in a moment.)

This effort represents the contributions of a core group of 15 to 18
people.  In 1988, 14 vendor organizations and 16 user organizations
were represented within the group.  Today, we have nine vendor
organizations and 16 user organizations represented.  Of course, the
only official, formal organizational representatives allowed within
IEEE working groups are accredited, institutional representatives
(currently Usenix, UniForum, X/Open, Unix International, and the Open
Software Foundation each supply one to the POSIX effort), but that
does not stop me from checking the sign-up sheet whenever a new face
shows up, to see where he or she works.  For example, I think someone
from the Univ. of Berkeley involved in BSD UNIX development has a
vendor's perspective, while I place attendees from NIST and the Air
Force in the user category because I believe they focus on the
interests of their own end users.  Our stable, steady user
representation is essential: our ultimate targets are users trying to
walk through the POSIX maze.

The 70% completion of our initial content goal includes the
introduction of the ``profile'' concept, which has led to increased
activity within the IEEE TCOS Standards Subcommittee to create groups
to define profiles (which may be good or bad depending on your own
prism).  The concept of profiles is also part of the US's contribution
to the ISO community, made through its participation in the JTC1
Technical Study Group on Application Portability (JTAP), within which
the ``profiles'' concept has now garnered wide acceptance.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 Standards Update                     IEEE 1003.0: POSIX Guide


                                - 2 -

``What is a profile?'' you ask.  Users seeking open system solutions
need to know what parts of the open system environment (OSE) address
their requirements.  If a user could reach into the full basket of OSE
parts and pull out only those he specifically needs, those selected
parts would be his application environment profile.  What he should do
if he needs something not in the basket?  Come to our next meeting
with a recommendation.  [Editor: Or drop Kevin a line, or post
something to comp.std.unix!]

Where we're going

Dot Zero still faces hard decisions in two areas:

  1.  the necessity or desirability of parts of our guide.  (Two parts
      that I very much think are candidates for this discussion are
      User Interface and Security)

  2.  The final bounds of the profile concept/definition.

The group's arguments in these areas are not frivolous, but if they
continue much longer, the resulting lack of movement will hurt our
overall effort.

I came out of this meeting feeling that everyone is committed to
getting over these hurdles soon (i.e., by the July meeting).  Our
chair, Al Hankinson, has also stated that we should target December,
1990 for a mock ballot.  I wholeheartedly agree.  This will add the
impetus that we need.  Let's see if we have the self-discipline to get
there.

May 1990 Standards Update                     IEEE 1003.0: POSIX Guide

Volume-Number: Volume 20, Number 3

From [e-mail]  Sat May 19 15:44:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28141; Sat, 19 May 90 15:44:21 -0400
Posted-Date: 19 May 90 19:32:16 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA06961; Sat, 19 May 90 14:44:15 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA11079; Sat, 19 May 90 14:32:52 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 May 90 19:32:16 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

ANSI X3B11.1: WORM File Systems

Andrew Hume <[e-mail]> reports on the April 17-19, 1990
meeting in Tucson, AZ:

Introduction

X3B11.1 is working on a standard for file interchange on write-once,
non-sequential (random access) media: a portable file system for
WORMs.  This was our fourth meeting.  With many major issues somewhat
settled, our main, remaining decisions are how to implement directory
hierarchies and how to manage free space.

Multi-Volume Sets

WORM file systems store a fair amount of information per file (such as
most of the fields in struct stat), per directory, per partition, and
per volume.  A volume is a logical address space associated with a
piece of physical media.  For example, a WORM disk that can only be
accessed one side at a time would be two volumes.  Each volume has a
label block describing its size, partitions, directory hierarchies,
free-space management, and so on.  (Free-space management is discussed
below; for now, this could mean a pointer to the next free block.)

Informally, multi-volume sets means files and directories can be
spread over several volumes.  Here are some requirements for this
feature:

   - A file can be bigger than a volume (file sizes are limited to
     2**64 bytes).

   - You can append to a file.

   - You can update any part of a file.

   - All volumes need not be simultaneously accessible.  (That is, if
     you have a three-volume volume set, you don't need three drives.)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


                                - 2 -

   - Each volume, and the whole volume set, must be consistent after
     an update.

   - Usable, although perhaps not fast, on a single drive.  The idea
     is that you can't mandate that the control structures for the
     volume set be distributed over the set, because that would mean
     that on single-drive systems, users might have to mount every
     volume to recover even a single file.  We would like to require
     only that the user mount the volume the file is on and perhaps
     one other (the master volume).

   - Each volume must be self-contained (for disaster recovery),

   - Security control is per volume, directory, and file.

After convincing ourselves that we all spoke roughly the same
language, we came to consensus decisions for the following questions:

   - Can a file description point to extents (files are spread across
     a list of extents) on later volumes? (Yes)

   - Can a directory entry point to a file description on a later
     volume? (Yes)

   - Must a directory be completely contained on a single volume? (No)
     Why?  There's no reason to require it.  All implementations are
     likely to use the same primitives to manage files and directories
     (that is, they'll implement directories as files); if you can
     handle multi-volume files correctly, directories should be easy
     too.  Some people were concerned about being able to get the
     directory in one (more or less) I/O or block (especially for MS-
     DOS) but that can't happen in general; directories and files are
     likely to be spread all over the volume.

   - must all the file descriptions for a single directory hierarchy
     fit on a single volume? (no)

   - should each volume of a volume set point to the volume describing
     the root of the main directory hierarchy for that set? (yes)

The above involve subtleties not readily apparent; details available
on request.

Directory Hierarchies

Much discussion centered on how to implement directory hierarchies --
at least, after our initial surprise discovery that we are committed
to support multiple directory hierarchies.  This commitment comes from
the CD-ROM standard, ISO 9660, where the intent was to have an ASCII
directory tree and one or more national-character-set trees.

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


                                - 3 -

[Editor: CD-ROMs, like WORMs, are on write-only media, but solve
different problems.  Both provide tremendous storage capacity, but
CD-ROMs appear to the user to be read-only, while WORMs appear to
provide read and write access.  Nevertheless, on WORMs, writing to a
file means either appending characters to a pre-allocated chunk of
disk, or rewriting a new version of the file in a new place.  Once a
file, or file version, is discarded, the piece of the physical medium
it's stored on is forever lost, not released for re-use.  CD-ROMs are
for storing the Encyclopedia Britannica; WORMs are for storing
backups.  ]

Our basic choice is between what I call the scattered directory tree,
which is much like the standard, UNIX file system, and path tables
(linearized encodings of the tree structure).  ISO 9660 supports both.
Scattered directories are simpler to deal with and somewhat easier to
update, but probably slow to access because they require too much
seeking.  Path tables seem faster at first glance (large contiguous
reads, etc.), but their simplicity and speed seem to evaporate when
the tables are modified.  There is no consensus on which method to
use.  I originally held out for two methods, a flexible one and a
really fast one, but have come to the conclusion, reinforced by
conversations with Ken Thompson, that it is better to have one
flexible method in the standard -- scattered directories --  and
handle accelerators, such as directory trees cached on magnetic disk,
as system-dependent structures outside the standard.

Suppose you update a file; doesn't that mean you also have to re-write
the directory, and, therefore, its parent directory, and, therefore,
its parent directory, and so on all the way up to the root directory?
And the volume header?  How do you find the root directory, the volume
header, and so on?  This stuff is not yet decided but we envision that
the file description stuff will have preallocated spare space so that
a few updates can be done without changing anything outside the file
description.  Once this space is full, the system will have to get
free space elsewhere, which implies updating some other area
describing the free space.  The volume header is in a fixed location
(probably 8KB in from the start of media) and will point to any later
volume headers and other stuff (such as where the root of the various
directory trees are).

Requirements for the directory hierarchy include space and time
efficiency, robustness (e.g., to minimize damage from a single I/O
error), a single, fast structure (unlike ISO 9660's two), and that a
directory entry for a file must be complete (that is, point to all the
extents for that file).

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


                                - 4 -

Space Allocation and Management

We must support pre-allocation of space (e.g., ``Reserve 40MB of
contiguous space for file `xyz'. '') both for speed and to support
systems like the MacIntosh.  Because of the latter, we also need to
support giving back unused reserved space for later use.

These two requirements appear to force the standard to address
describing the free space in a volume set, which will also be
important if the standard is extended to cover R/W optical disks,
where freed blocks need to be cleared before reuse.  The two choices
appear to be run-length encodings of the free space or bitmap
techniques.  The former can degrade to being quite large, while the
latter have a fixed, but high, overhead (current media hold up to
8.2GB/side!).

Finale

We hope to conduct a letter ballot soon after the October, 1990
meeting.  If we can approve a proposal by January, 1991 then it may be
an ANSI standard by January, 1992.  Our next meeting is in Murray
Hill, New Jersey, on July 17-19, where we expect to adopt the proposal
being edited by Howard Kaikow as our working proposal.  Anyone
interested in attending should contact either the chairman, Ed Beshore
([e-mail]), or me ([e-mail]).

While this standard may seem of limited interest, because it deals
only with WORMs, X3B11.1 expects approval shortly to develop a similar
standard for R/W optical media.  It doesn't take much imagination to
see that standard being extended to apply to all rewritable, direct-
access media.  (Unlike the CD-ROM standards committee, which ignored
UNIX, this committee has a significant number of UNIX users, including
representatives from AT&T Bell Labs, Sun, Hewlett-Packard.  That, at
least, insures filenames won't be required to have a compulsory
three-character suffix and a version number.) Once we have a working
paper, anyone who cares about portable, multi-volume, multiple-
character-set file systems should take a look.  [Editor: Pay
attention.  He's giving you fair warning.]

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


Volume-Number: Volume 20, Number 4

From [e-mail]  Sat May 19 15:44:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28156; Sat, 19 May 90 15:44:38 -0400
Posted-Date: 19 May 90 19:34:52 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA06978; Sat, 19 May 90 14:44:34 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA11134; Sat, 19 May 90 14:35:24 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 May 90 19:34:52 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions

Rick Greer <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

1003.4

The .4 ballots went out on schedule, and most came back on schedule as
well.  We (barely) got the required 75% response, of which 43%
approved of the draft as it stood.  The small-group leaders are
currently working to resolve the objections and will report back at
Danvers, in July.

1003.4a

Most of the work at Snowbird centered around threads (.4a).  Two
alternatives to the pthreads proposal were presented at the meeting:
``strands'', from John Zolnowsky of Sun, defined a minimal set of
interfaces for multi-threaded applications; ``VP'', from Paul Borman
of Cray, added a ``virtual processor'' layer to the pthreads
specification, which made some multiprocessor (MP) features visible to
applications.

The primary MP hardware feature that Paul's VP proposal makes visible
to the pthreads environment is the ability to write your own spin
loops and expect them to work.  One could, for example, have one
thread continuously reading an in-core data base while another thread
updates it.  On an MP system, it might be more efficient to code this
without using a mutex, although doing so on a uni-processor with a
co-routine threads package is an absolute disaster.  The new
multiprocessor group, 1003.16, is looking into this and similar
problems, and will probably suggest that .4a include some sort of
system-wide attribute structure that one can check when writing
programs that depend heavily on concurrent execution of threads.

After a week's discussion (often a euphemism for argument), we settled
into a compromise position not that far from where we started --
 pthreads.  All this work without much net change was frustrating, but

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 Standards Update            IEEE 1003.4: Real-time Extensions


                                - 2 -

probably unavoidable.  Until fairly recently most of the committee was
busy getting the .4 draft ready for balloting.  Lacking enough time to
have studied threads carefully, members were unwilling to accept the
small group's conclusions before investigating some alternatives for
themselves.  Still, some progress was made.  The most important was a
more comprehensive definition of signal behavior in multi-threaded
programs.

1003.14

On the last day, a first attempt at a real-time application
environment profile (AEP) was presented.  This PAR will be an
excellent, practical test of AEPs.  Real-time applications are likely
to vary wildly in the subsets of .4's rich features that they require.
Some worry that the real-time AEP will force embedded systems that
need only one or two .4 features to incorporate others just to adhere
to the standard.  The problem this poses is not just storage space
wasted by unused code, but the expense of verifying that this extra
code will never get in the way of the application.  The group will be
wrestling with these and similar problems in the months to come.

May 1990 Standards Update            IEEE 1003.4: Real-time Extensions


Volume-Number: Volume 20, Number 5

From [e-mail]  Sun May 20 17:28:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20518; Sun, 20 May 90 17:28:14 -0400
Posted-Date: 20 May 90 03:08:17 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA18185; Sun, 20 May 90 16:28:10 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13321; Sun, 20 May 90 16:05:38 cdt
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 20 May 90 03:08:17 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
-> SVID 3 (System V Release 4.0), OSF AES (OSF/1), Berkeley BSD 4.4, MACH
-> 2.5, ULTRIX, SunOS, HP/UX, etc, all include an (almost) identical
-> definition of mmap() based on the current Sun/Berkeley specification.
-V.3.2 does not include this interface, and V.3.2 is going to be around,
-and in fact very common, for at least a couple of years to come. A standard
-that locks out V.3.2 is going to hurt portability.
-I believe that implementing shared memory in terms of memory mapped files
-is a good thing, and that every effort should be made to encourage it...
-within reason. Preventing the implementation of POSIX shared memory on
-the largest installed base of UNIX systems in existence is not within
-reason.

The goal of POSIX was not to bless existing botched implementations!
4.3BSD also does not provide a working mmap(), and it also fails to
comply with 1003.1 in numerous ways.  This is being addressed by making
a future release (4.4BSD) POSIX-compliant, not by making 1003.1 cater
to existing deficiencies.  Similarly for the real-time extensions.
If 1003.1 had had to avoid making implementors improve their products,
it would have been of even less practical use than the /usr/group 1984
standard.

-    a) People with "real mmap" will end up using more than the
-       standard allows. This is a pretty simple prediction... look
-       at existing extended implementations.
-    b) People with the "fake mmap" will end up blowing the extra
-       parameters, "safely". Then when run on a system with the real
-       thing their programs will fail.

    c) People who are concerned with portability with not stray
       outside the domain that the standard guarantees to work.

You seem to be arguing that extensions should be prohibited.

Volume-Number: Volume 20, Number 6

From [e-mail]  Mon May 21 09:17:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AB08280; Mon, 21 May 90 09:17:52 -0400
Posted-Date: 20 May 90 23:18:57 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA12966; Mon, 21 May 90 08:17:45 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA15624; Mon, 21 May 90 08:13:05 cdt
From: Peter da Silva <ficc.ferranti.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 20 May 90 23:18:57 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] writes:
> The goal of POSIX was not to bless existing botched implementations!

If that's the case, why doesn't 1003.1 require 255-character file names?

It has been observed in the past, by many people, that the most successful
standards have been conservative ones. Standards that basically blessed
what people have been doing anyway...

>     c) People who are concerned with portability with not stray
>        outside the domain that the standard guarantees to work.

In the real world, people will write programs using their system and manual
as a working base. If their system says that mmap() works such-and-such a
way, they'll use it. They may even think that their program is portable,
because mmap is in 1003.4.

> You seem to be arguing that extensions should be prohibited.

No, I'm arguing that extensions should be explicit. You should have to perform
some magic juju so that you *know* you're stepping outside the POSIX consulate
into the anarchic land of Vendor-Specificia.

Like calling mmap() instead of whatever the POSIX routine is.
--
`-_-' Peter da Silva. [phone].  <[e-mail]>
 'U`  Have you hugged your wolf today?  <[e-mail]>
@FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.

Volume-Number: Volume 20, Number 7

From [e-mail]  Tue May 22 09:30:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17409; Tue, 22 May 90 09:30:47 -0400
Posted-Date: 21 May 90 16:01:48 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA23774; Tue, 22 May 90 08:30:43 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01957; Tue, 22 May 90 07:38:11 cdt
From: <Wichita.NCR.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Tape Driver standards?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 May 90 16:01:48 GMT
Apparently-To: [e-mail]

From: uunet!Wichita.NCR.COM!Alden.Wilner
From:  [e-mail]

I am interested in finding out the current state of standards efforts
in regards to tape drivers, specifically:

Is there any standard ioctl interface to take advantage of the flexibility
afforded by the SCSI interface?

I have heard rumors that AT&T has come up with a proposal (or perhaps a
de-facto standard in SVR4), but don't have any details.  Can anyone
supply me with some?

Is there any standard action for what a tape driver should do with
internal flags (End-Of-Media, Filemark, etc.) when it receives an ioctl
call (like, clear the "DataWritten" flag so filemark writing won't be
performed after an ioctl)?

Is there any standard defined for what drivers should do with the
bp->b_blkno?  Early AT&T drivers (the Kennedy tape drive?) would
support block device IO to tapes, and would space the requested number
of 512-byte blocks if the b_blkno didn't match the driver's idea of
where it was.  So what happens with, say, 5K blocks on a 1/2" tape
reel?  Or should the driver just ignore the bp->b_blkno field
altogether?

These questions are prompted by the infamous exabyte tape drive.  Since
that thing's so huge, it would be nice to have a way to space around on
the tape so you can write multiple disk backups to a single tape (as,
for example, the Willow tape backup system does).  And it would be
really nice if this method were standardized, either at the ioctl level
or at a library which would translate standard function calls to
whatever the driver prefers for ioctl.

Standard ioctl - what a concept.

Thanks,
[e-mail]

Volume-Number: Volume 20, Number 8

From [e-mail]  Tue May 22 09:31:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17486; Tue, 22 May 90 09:31:09 -0400
Posted-Date: 21 May 90 19:49:40 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA23789; Tue, 22 May 90 08:30:59 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02134; Tue, 22 May 90 07:46:35 cdt
From: Maarten Litmaath <cs.vu.nl![e-mail]>
Newsgroups: comp.std.unix
Subject: sh pipelines and subshells (was: Braces in the Shell)
Summary: ``some_command | read foo'' should work
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Maarten Litmaath <[e-mail]>
Followup-To: comp.std.unix
Organization: VU Informatika, Amsterdam, The Netherlands
Date: 21 May 90 19:49:40 GMT
Apparently-To: [e-mail]

From:  Maarten Litmaath <[e-mail]>

In article <[e-mail]> in the newsgroup
comp.unix.questions, [e-mail] (Chet Ramey) writes:
)...
)I quote (without comment) from P1003.2, draft 9, section 3.12.0.1:
)
)"It was decided to allow this extension [running the last process in a
) pipeline in the current environment], but not require it; therefore, a
) shell programmer should consider a pipeline to be in a subshell environment,
) but not depend on it."
)
)and from section 3.12:
)
)"Additionally, each command of a multi-column pipeline is in a subshell
) environment; as an extension, however, any or all commands in a pipeline
) may be executed in the current environment."
)
)
)It seems they have already considered this proposal (I imagine David Korn
)brought it up).

They've considered it indeed, but I don't like the outcome: ambiguity!
If I write a shell script I want to know *exactly* what'll happen on
another POSIX system: that's the whole purpose of P1003.2!
Let's see:

    "[...] a shell programmer should consider a pipeline to be in
    a subshell environment, but not depend on it."

What does this buy me?  Nothing!  What would you think of the following?

    "A shell programmer should consider a string beginning with a
    dollar sign to be a shell variable, but not depend on it."

Ridiculous, right?  Right.
My proposal:

    If the last command of a pipeline is a (`special') builtin
    command, it must be run in the current environment, else in
    a private environment, just like the other components of the
    pipeline.

In fact I would even accept *every* component that's a (`special')
builtin command, to run in the current environment, so the following
would work:

    command_1 |
    while read line
    do
        something
        echo "$line"
        last=$line
    done |
    command_2

    echo "The last line was: $last"

...but I realize this could be difficult to implement.  On the other hand
the *last* command in a pipeline is a straightforward case.  At that the
next (well-known) example isn't that obscure at all:

    some_command | read answer

In current implementations this won't work as intended.  The workarounds
are ugly, as workarounds often are.  (Boy, do I hate temp files.)

OK, but what if the user *wants* a subshell?!  Easy, he would use
parentheses, just like always:

    foo=$orig
    another_command | (
        while read foo
        do
            bar
        done
    )
    echo "foo is $foo and should still be $orig"
--
 Antique fairy tale: Little Red Riding Hood. |Maarten Litmaath @ VU Amsterdam:
 Modern fairy tale: Oswald shot Kennedy. |[e-mail], uunet!cs.vu.nl!maart

Volume-Number: Volume 20, Number 9

From [e-mail]  Wed May 23 14:06:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04717; Wed, 23 May 90 14:06:48 -0400
Posted-Date: 22 May 90 01:25:49 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA25717; Wed, 23 May 90 13:06:41 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05882; Wed, 23 May 90 12:44:29 cdt
From: <mindcrf![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Summary: Portability checking
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Mindcraft, Inc.
Date: 22 May 90 01:25:49 GMT
Apparently-To: [e-mail]

From:  [e-mail]

In article <[e-mail]> Peter da Silva wrote:
>In article <[e-mail]> [Doug Gwyn] writes:
>>     c) People who are concerned with portability with not stray
>>        outside the domain that the standard guarantees to work.
>
>In the real world, people will write programs using their system and manual
>as a working base. If their system says that mmap() works such-and-such a
>way, they'll use it. They may even think that their program is portable,
>because mmap is in 1003.4.
>
>> You seem to be arguing that extensions should be prohibited.
>
>No, I'm arguing that extensions should be explicit. You should have to perform
>some magic juju so that you *know* you're stepping outside the POSIX consulate
>into the anarchic land of Vendor-Specificia.

This sounds like a job for... the Mindcraft C Portability Verifier!
Among other things, this product lets you check conformance to ANSI C,
1003.1, 1003.2 C interfaces, XPG3, or any other standard for which you
write a definition.  Pick any one of these standards or any combination
of them.

I'll post a full description to comp.newprod.

Vaporware right now, but condensing even as I type.  It'll ship a few
weeks from now.

>Like calling mmap() instead of whatever the POSIX routine is.

I hope we don't have to name a new interface every time a new standard
restricts or changes the syntax of an old one.  Especially when the
old interface is difficult to use portably anyway.
--

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

Volume-Number: Volume 20, Number 10

From [e-mail]  Tue May 22 09:31:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17584; Tue, 22 May 90 09:31:27 -0400
Posted-Date: 22 May 90 02:32:04 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA23805; Tue, 22 May 90 08:31:17 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02589; Tue, 22 May 90 08:19:38 cdt
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 22 May 90 02:32:04 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
-If that's the case, why doesn't 1003.1 require 255-character file names?

Because it wasn't necessary to do so.

->     c) People who are concerned with portability with not stray
->        outside the domain that the standard guarantees to work.
-In the real world, people will write programs using their system and manual
-as a working base. If their system says that mmap() works such-and-such a
-way, they'll use it. They may even think that their program is portable,
-because mmap is in 1003.4.

I like to think I'm working in the real world, and because I do care
about application portability I'm careful about these things when I
program.  I suspect I'm not the only one.  Note that there IS no magic
road to guaranteed portability, if the programmer is oblivious to the
issues.

-> You seem to be arguing that extensions should be prohibited.
-No, I'm arguing that extensions should be explicit. You should have to perform
-some magic juju so that you *know* you're stepping outside the POSIX consulate
-into the anarchic land of Vendor-Specificia.

That would be nice, but it's pretty hard to enforce in cases like
adding extended functionality to the standard functions.

Volume-Number: Volume 20, Number 11

From [e-mail]  Tue May 22 11:06:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06178; Tue, 22 May 90 11:06:45 -0400
Posted-Date: 22 May 90 14:12:41 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA00949; Tue, 22 May 90 10:06:37 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03141; Tue, 22 May 90 09:13:20 cdt
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
Expires: 1 Jul 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Followup-To: comp.std.unix
Date: 22 May 90 14:12:41 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne W. Smith)

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.

If your favorite meeting is not listed, it's probably because we don't know
about it.  If you send me <[e-mail]> information on it, we will
probably list it both here and in the appropriate one of the companion
articles:
        Access to UNIX User Groups
        Access to UNIX-Related Publications
        Access to UNIX-Related Standards

These access postings are collected and posted by Susanne W. Smith of
Windsound Consulting <[e-mail]> and were originated by John S.
Quarterman of Texas Internet Consulting <[e-mail]>.  The
information comes from the various conference organizers, Alain Williams
(EUUG), ;login:, Communications of the ACM, CommUNIXations, and many
others. We encourage others to reuse this information, but we ask for
proper acknowledgment, for example by including this statement.

Changes since last posting: Numerous additions, UNIX/90 has become the
        Multi-User Computer Show.

Abbreviations:
          APP   Application Portability Profile
            C   Conference or Center
           CC   Computer Communication
        CT&LA   Conformance Testing & Laboratory Accreditation
        G, MD   Gaithersburg, Maryland
          MHS   Message Handling Systems & Application Layer Communication
                Protocols
          OSE   Open Systems Environment
            S   Symposium
            T   Tradeshow
            U   UNIX
           UG   User Group
            W   Workshop

USENIX, UniForum, EUUG, AUUG, and DECUS sponsor conferences of the same
names.

UNIX is a Registered Trademark of AT&T Bell Laboratories.

TIC <[e-mail]>                    Windsound <[e-mail]>

90/05/21 pg. 2        Calendar of UNIX-Related Events         comp.std.unix

year mon days     conference             (sponsor,) (hotel,) location
1990 May 21-24    Xhibition 90           San Jose, CA
1990 May 23-24    5th AMIX C             AMIX, Ramat-Gan, Israel
1990 May 24-28    ENA Annual C           Pacific Bell C Center, SF, CA
1990 May 30-Jun 1 Multi-User Comp. Show  UniForum Canada, Toronto, ON
1990 Jun 11-15    USENIX                 Marriott, Anaheim, CA
1990 Jul 9-11     15th JUS S             JUS, Tokyo, Japan
1990 Jul 9-13     UKUUG C                London,UK
1990 Jul 10       POSIX Conform. Test W  NIST, G, MD
1990 Jul 16-20    IEEE 1003              Danvers, MA
1990 Jul 23-25    Sun Expo               San Jose, CA
1990 Jul 31-Aug 3 IETF                   IAB, U. British Columbia, Vancouver, BC
1990 Aug 6-10     SIGGRAPH 90 C          ACM, Dallas, TX
1990 Aug 20-23    Interex C              Interex, Boston, MA
1990 Aug 27-28    U Security W           USENIX, Portland, OR
1990 Sept 3-7     DECUS Europe S         Cannes, France
1990 Sept 4-6     GUUG C                 Wiesbaden, Germany
1990 Sept 20-21   Sun UK UG C            Edinburgh, UK
1990 Sep 24-26    SIGCOMM 90 C           ACM, Philladelphia, PA
1990 Sep 25-28    AUUG C                 World Congress Centre, Melbourne, Australia
1990 Oct 3-5      Internat'l S of MHS    IFIP WG 6.5, Zurich, Switzerland
1990 Oct 4-5      Mach W                 USENIX, Burlington, VT
1990 Oct 8-12     InterOp 90             ACE, San Jose, CA
1990 Oct 15-19    IEEE 1003              Seattle, WA
1990 Oct 17-19    Large Inst. SysAdmin W USENIX, Colorado Springs, CO
1990 Oct 22-25    IPA C                  Jerusalem, Israel
1990 Oct 22-26    EUUG                   Nice, France
1990 Oct 31-Nov 2 UNIX EXPO              New York, NY
1990 Nov 5-9      10th Int'l C on CC     ICCC, New Delhi, India
1990 Nov 8        Open Systems C         NLUUG, Ede, Netherlands
1990 Nov 14-16    UNIX EXPO '90          UniForum Swedish, Stockholm, Sweden
1990 Nov 15       APP/OSE Users Forum    NIST, G, MD
1990 Nov 15-16    16th JUS S             JUS, Osaka, Japan
1990 Dec 2-5      Sun User Group         San Jose, CA
1990 Dec 4-5      JUS UNIX Fair '90      JUS, Tokyo, Japan
1990 Dec 4-7      IETF                   IAB, U. Colorado, Boulder, CO
1990 Dec 10-12    Unix Asia '90 C        Sinix, Singapore
1990 Dec 10-14    DECUS S                Las Vegas, NV
1990 Dec 13-16    Unix Pavilion '90 T    Sinix, Singapore
1990 Dec 17-19    UKUUG C                Cambridge, UK

TIC <[e-mail]>                    Windsound <[e-mail]>

90/05/21 pg. 3        Calendar of UNIX-Related Events         comp.std.unix

1991 Jan 7-11  IEEE 1003                   New Orleans, LA
1991 Jan 21-25 USENIX                      Grand Kempinski, Dallas, TX
1991 Jan 21-24 UniForum                    Infomart, Dallas, TX
1991 Jan 16-17 Multi-User C Show for Gov't UniForum Canada, Ottawa, ON
1991 Feb 18-22 DECUS S                     Ottawa, Canada
1991 Mar       IETF                        IAB, Wash. U, St. Louis, MO (tentative)
1991 Mar 13-20 CeBIT 91                    Hannover, Germany
1991 Mar 26-29 AFUU C                      CNET Paris La Defense, France
1991 Apr 10-12 Standards W                 IEEE, USENIX, UniForum, EUUG (tentative)
1991 Apr 15-19 IEEE 1003                   Houston, TX (location tentative)
1991 May 15-17 Multi-User C Show           UniForum Canada, Toronto, ON
1991 May 9     APP/OSE Users Forum         NIST, G, MD
1991 May 6-10  DECUS S                     Atlanta, GA
1991 May 20-24 EUUG                        Tromso, Norway
1991 Jun 10-14 USENIX                      Opryland, Nashville, TN
1991 Jun 17-19 Sun User Group              Atlanta, GA
1991 Jun/Jul   UKUUG C                     Liverpool, UK
1991 Jul 8-12  IEEE 1003                   Santa Clara, CA (location tentative)
1991 Sep 16-20 EUUG                        Budapest, Hungary
1991 Oct 10-11 Multi-User C Show           UniForum Canada, Montreal, Quebec
1991 Oct 21-25 IEEE 1003                   Southern Europe (location tentative)
1991 Nov 14    APP/OSE Users Forum         NIST, G, MD
1991 Dec       UKUUG C                     Edinburgh, UK
1991 Dec 9-11  Sun User Group              San Jose, CA
1991 Dec 9-13  DECUS S                     Anaheim, CA

1992 Jan 13-17    IEEE 1003            Orlando, FL (location tentative)
1992 Jan 20-24    USENIX               Hilton Square, San Francisco, CA
1992 Jan 20-23    UniForum             Moscone Center, San Francisco, CA
1992 Spring       EUUG                 Jersey, U.K.
1992 Mar 11-18    CeBIT 92             Hannover, Germany
1992 Apr 20-24    IEEE 1003            Montreal, PQ (location tentative)
1992 May 4-8      DECUS S              Atlanta, GA
1992 Jun 8-12     USENIX               Marriott, San Antonio, TX
1992 Jun 22-24    Sun User Group       Washington, DC
1992 Jul 13-17    IEEE 1003            Alaska (location tentative)
1992 Autumn       EUUG                 Amsterdam, Netherlands
1992 Oct 19-23    IEEE 1003            Scottsdale, AZ (location tentative)

1993 Jan          USENIX               Town & Country, San Diego, CA
1993 Mar 15-18    UniForum             Moscone Center, San Francisco, CA
1993 Mar 24-31    CeBIT 93             Hannover, Germany
1993 Jun 21-25    USENIX               Cincinnati, OH

TIC <[e-mail]>                    Windsound <[e-mail]>

90/05/21 pg. 4        Calendar of UNIX-Related Events         comp.std.unix

1994 Feb 7-10     UniForum             Dallas Convention Center, Dallas, TX
1994 Mar 16-23    CeBIT 94             Hannover, Germany
1994 Jun          USENIX               Boston, MA
1995 Mar 6-9      UniForum             Dallas Convention Center, Dallas, TX
1996 Mar 11-14    UniForum             Moscone Center, San Francisco, CA
1997 Mar 10-13    UniForum             Moscone Center, San Francisco, CA

TIC <[e-mail]>                    Windsound <[e-mail]>


Volume-Number: Volume 20, Number 12

From [e-mail]  Tue May 22 11:08:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06885; Tue, 22 May 90 11:08:55 -0400
Posted-Date: 22 May 90 14:19:20 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA01210; Tue, 22 May 90 10:08:37 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03275; Tue, 22 May 90 09:20:46 cdt
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups
Message-Id: <[e-mail]>
Expires: 1 Jul 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 22 May 90 14:19:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne W. Smith)

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there.

There are three related articles, posted at the same time as this one,
with subjects
    Calendar of UNIX-related Events
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Corrections and additions to this article are solicited.  I keep track
of the conferences, groups, and publications that I attend, am a member
of, or subscribe to.  All others (the majority of the listings) I derive
either from listings elsewhere, or from contributions by readers.
In particular, the meeting schedules and descriptions of most of the
groups are provided by their members.  If a group doesn't have a
meeting schedule listed, it's because nobody has sent me one.  This is
a low-budget operation:  I publish what I have on hand when the time
comes (approximately bi-monthly).

Changes since last posting: Sun User Group, New DECUS phone number,
        USENIX workshops, /usr/group/cdn is now UniForum Canada.

Access information is given in this article for the following:
user groups:    USENIX, UniForum, UNIX Expo, UniForum Canada,
        EUUG, AFUU, UKUUG, /usr/group/uk, GUUG, i2u, NLUUG
        UUGA, BUUG, DKUUG, FUUG, HUUG, ICEUUG, Interex, IUUG,
        NUUG, PUUG, EUUG-S, YUUG,
        AMIX, AUUG, NZUSUGI, JUS, KUUG, MALNIX, Sinix, CUUG, ICX89,
        DECUS UNIX SIG, Sun User Group (SUG),
        Apollo DOMAIN Users' Society (ADUS),
        Open Software Foundation (OSF),
        UNIX International (UI).

Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.

UNIX is a Registered Trademark of AT&T.


USENIX is ``The Professional and Technical UNIX(R) Association.''

        USENIX Association
        2560 Ninth Street
        Suite 215
        Berkeley, CA 94710
        U.S.A.
        tel: [phone]
        fax: [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:

1990 Jun 11-15    USENIX            Marriott Hotel, Anaheim, CA
1990 Aug 27-28    UNIX Security Workshop    Portland, OR
1990 Oct 4-5    Mach Workshop        Burlington, VT
1990 Oct 17-19  Large Inst. Sys. Admin. W      Colorado Springs, CO
1991 Apr 10-12  Standards W         w/ IEEE, UniForum, EUUG (tentative)
1991 Jan 21-25    USENIX            Grand Kempinski, Dallas, TX
1991 Jun 10-14    USENIX            Opryland, Nashville, TN
1992 Jan 20-24    USENIX            Hilton Square, San Francisco, CA
1992 Jun 8-12    USENIX            Marriott, San Antonio, TX
1993 Jan    USENIX            Town & Country, San Diego, CA
1993 Jun 21-25    USENIX            Cincinnati, OH
1994 Jun    USENIX            Boston, MA

Proceedings for all conferences and workshops are available at
the door and by mail later.  Some of the older ones have been
out of print, but the office will duplicate small quantities for you.

USENIX publishes ``;login:  The USENIX Association Newsletter''
bimonthly.  It is sent free of charge to all their members and
includes technical papers.  There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.

In 1988, USENIX started publishing a refereed quarterly
technical journal, ``Computing Systems:  The Journal of the USENIX
Association,'' in cooperation with University of California Press.

They also publish an edition of the 4.3BSD manuals and distribute the
2.10BSD software distribution.  They coordinate a software exchange for
appropriately licensed members.  They occasionally sponsor experiments,
such as methods of improving the USENET and UUCP networks (e.g., UUNET),
that are of interest and use to the membership.

There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
There is also a USENIX Standards Watchdog Committee following several
standards bodies.  For more details, see the posting in comp.std.unix,
``Access to UNIX-Related Standards.''


UniForum (formerly /usr/group) is a non-profit trade association dedicated
to the promotion of products and services based on the UNIX operating system.

        UniForum
        2901 Tasman Drive
        Suite 201
        Santa, Clara, CA  95054
        U.S.A.
        tel: [phone]
        fax: [phone]

UniForum sponsors an annual conference and trade show which
features vendor exhibits, as well as tutorials and technical sessions.

1991 Jan 21-24    UniForum    Infomart, Dallas, TX
1991 Apr 10-12  Standards W     w/IEEE, USENIX, EUUG (tentative)
1992 Jan 20-23    UniForum    Moscone Center, San Francisco, CA
1993 Mar 15-18    UniForum    Moscone Center, San Francisco, CA
1994 Feb 7-10    UniForum    Dallas Convention Center, Dallas, TX
1995 Mar 6-9    UniForum    Dallas Convention Center, Dallas, TX
1996 Mar 11-14    UniForum    Moscone Center, San Francisco, CA
1997 Mar 10-13    UniForum    Moscone Center, San Francisco, CA

Proceedings for all conferences are available at the shows and later
by mail.

UniForum publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.

UniForum also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``UniNews'', formerly ``/usr/digest'', is also published by UniForum.
This newsletter covers product announcements and industry projections,
and is sent biweekly to General members of UniForum and to non-member
subscribers.

UniForum has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the UniForum Technical Committee
on areas that P1003 has not yet addressed. They publish the documents,
``Your Guide to POSIX,'' explaining what IEEE 1003 is,  ``POSIX Explored:
System Interface,'' about technical aspects of IEEE 1003.1, and its relations
to other standards and historical implementations, and ``POSIX Update: Shell
and Utilities.'' They also funded production of a draft of a ``Rationale and
Notes'' appendix for IEEE 1003.1.


UNIX EXPO is an annual very large vendor exhibit in New York City
with tutorials and technical presentations.  It is held at the
Jacob K. Javits Convention Center, with lodging arrangements with
the Sheraton Centre Hotel, both in Manhattan.

1990 Oct 31-Nov 2 UNIX EXPO        New York, NY

        National Expositions Co., Inc.
        15 West 39th Street
        New York, NY 10018
        U.S.A.
        tel: [phone]
        fax: [phone]

        Reservations Department
        Sheraton Centre Hotel
        811 Seventh Avenue
        New York, NY 10019
        U.S.A.
        Tel: [phone]
        Fax: [phone]
        Telex: 421130


UniForum Canada is the Canadian branch of UniForum, and holds an
annual spring conference and trade show modeled after UniForum,
usually at the Metro Toronto Convention Center.  They also hold
a UNIX in Government show in the winter in Ottawa.

Exhibitors and attendees can contact:
        Fawn Lubman
        Communications 2000
        4195 Dundas St. #201
        Etobicoke, Ontario M8X 1Y4
        Canada
        [phone]

        UniForum Canada
        241 Gamma St.
        Etobicoke, Ontario M8W 4G7
        Canada
        [phone]

1990 May 30-Jun 1 Multi-User Computer Show    UniForum Canada, Toronto, ON
1991 Jan 16-17    Multi-User Computer Show    UniForum Canada, Ottawa, ON
               for Government
1991 May 15-17    Multi-User Computer Show    UniForum Canada, Toronto, ON
1991 Oct 10-11    Multi-User Computer Show    UniForum Canada, Montreal, Quebec

UNIForum Swedish holds an annual conference.

    UNIForum Swedish AB
    Torshamnsgatan 39
    S-16440 KISTA
    SWEDEN
    Tel: [phone]
    Fax: [phone]

1990 Nov 14-16    UNIX EXPO 90    Alvsjo, Stockholm, Sweden


EUUG is the European UNIX systems Users Group. EUUG is closely coordinated
with national groups in Europe, and with the European UNIX network, EUnet.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        [phone]
        fax: [phone]
        uunet!mcvax!inset!euug
        [e-mail]

They have a quarterly newsletter, EUUGN, and hold two conferences a year:

1990 Oct 22-26    EUUG        Nice, France
1991 Apr 10-12  Standards W     w/IEEE, USENIX, UniForum (tentative)
1991 May 20-24     EUUG        Tromso, Norway
1991 Sep 16-20    EUUG        Budapest, Hungary
1992 Spring    EUUG        Jersey, U.K. (tentative)
1992 Autumn    EUUG        Amsterdam, Netherlands (tentative)


AFUU is the Association Franc\*,aise des Utilisateurs d'UNIX,
or French UNIX Users' Group.  They usually hold a small convention
in November and a large one in the spring with tutorials and a
vendor exhibit.

        AFUU
        Miss Ann Garnery
        11 Rue Carnot
        94270 Le Kremlin Bicetre
        Paris
        France
        [phone]
        Fax: [phone]
        [e-mail]

1991 Mar 26-29    AFUU    CNET Paris La Defense, France

UKUUG is the United Kingdom Unix systems Users' Group.

        Bill Barrett
        UKUUG
        Owles Hall
        Buntingford
        Herts. SG9 9PL
        United Kingdom
        [phone]
        Fax: [phone]
        [e-mail]

1990 Jul 9-13   UKUUG C London,UK
1990 Dec 17-19  UKUUG C Cambridge, UK
1991 Jun/Jul    UKUUG C Liverpool, UK
1991 Dec        UKUUG C Edinburgh, UK

UniForum UK is the U.K. affiliate of UniForum, and holds an annual
COMUNIX Conference in June in conjunction with the European UNIX User Show,
which is an exhibition organised by EMAP Internation Exhibitions.

        Tracy MacIntyre
        Exhibition Manager
        EMAP International Exhibitions Ltd.
        Abbot's Court
        34 Farringdon Lane
        London EC1R 3AU
        United Kingdom
        [phone]

The German UNIX Systems User Group (GUUG) has an annual convention in the fall.

        GUUG (German Unix User Group)
        Dr Anton Gerold
        Elsenheimerstr 43
        D-8000 Muenchen 21
        Federal Republic of Germany
        [phone]
        Fax: [phone]
        [e-mail]

1990 Sept 4-6   GUUG C  Wiesbaden, Germany

The Italian UNIX Systems User Group (i2u) holds an annual summer
Italian UNIX Convention, with tutorials and a vendor exhibition.

        Carlo Mortarino
        i2u Secretariat
        Via Monza, 347
        20126 Milano
        Italy
        [phone]
        [e-mail]

The Netherlands UNIX Users Group (NLUUG) holds a fall conference with
technical sessions and tutorials.

        Netherlands (NLUUG)
        Patricia H. Otter
        c/o Xirion bv.
        World Trade Centre
        Strawinskylaan 1135
        1077 XX Amsterdam
        The Netherlands
        [phone]
        patricia@hp4nl or nluug@hp4nl

1990 Nov 8      Open Systems C  NLUUG, Ede, Netherlands

The following information about European groups courtesy EUUG:

        Austria (UUGA)
        Friedrich Kofler
        Schottenring 33/Hof
        A-1010 Vienna
        Austria
        Tel: [phone]
        [e-mail]

        Belgium (BUUG)
        Marc Nyssen
        Department of Medical Informatics
        VUB
        Laarbeeklaan 103
        B-1090 Brussels
        Belgium
        [phone] Ext. 1424
        Fax: [phone]
        [e-mail]

        Denmark (DKUUG)
        Mogens Buhelt
        Kabbeleejvej 27B
        DK-2700 Bronshoj
        Denmark
        Tel: [phone]
        [e-mail]

        Finland (FUUG)
        Anu Patrikka-Cantell
        Finnish UNIX Users' Group
        Arkadiankatu 14 B 45
        00100 Helsinki
        Finland
        Tel: [phone]

        Hungary (HUUG)
        Dr Elod Knuth
        Computer and Automation Institute
        Hungarian Academy of Sciences
        P.O. Box 63
        H-1502 Budapest 112
        Hungary
        [phone]
        Fax: [phone]



        Iceland (ICEUUG)
        Marius Olafsson
        University Computer Center
        Hjardarhaga 4
        Dunhaga 5
                Reykjavik
        Iceland
        [phone]
        [e-mail]

        Ireland (IUUG)
        Norman Hull
        Irish UNIX Systems User Group
        Court Place
        Carlow
        Ireland
        Tel: [phone]
        Fax: [phone]
        [e-mail]

        Norway (NUUG)
        Jan Brandt Jensen
        NUUG
        c/o Unisoft A.S.
        Enebakkvn 154
        N-O680 Oslo 6
        Norway
        [phone]
        ndosl!ZEUS!jan

        Portugal  (PUUG)
        Legatheaux Martens
        Avenue 24 de Julho
        Lisboa
        Portugal
        Tel: [phone]/609822
        Fax: [phone]
        [e-mail]


        Sweden (EUUG-S)
        Hans Johansson
        NCR Svenska AB
        Box 1206
        S-164 28 Kista
        Sweden
        Tel: [phone]
        [e-mail]

        Yugoslavia  (YUUG)
        Milan Palian
        Iskra Delta Computers
        Parmova 41
        61000 Ljubljana
        Yugoslavia
        Tel: [phone]
        [e-mail]



AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli
Processing Association (IPA). AMIX has a yearly conference including
an exhibition, and a mid year sequence of tutorials and workshops.

                Israeli UNIX User Group (AMIX)
                c/o IPA, P.O.Box 919
                attn: Ariel J. Frank
                Ramat-Gan, Israel, 52109
                [e-mail]
                [e-mail]
                +972-3-715770,715772
                fax: [phone]

1990 May 23-24  5th AMIX Conference     AMIX, Ramat-Gan, Israel


AUUG is the Australian UNIX systems Users Group.

        Tim Roper
        Secretary
        AUUG
        [e-mail]
        uunet!labtam.oz.au!timr

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia
        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds one major national Conference and Exhibition per year during
August or September.

1990 Sep 25-28  AUUG    World Congress Centre, Melbourne, Australia

AUUG also holds regional summer meetings to provide an information
forum for the presentation of technical issues of interest to programmers,
system administrators, and experiences users.

They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.


The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
and publishes a newsletter, ``NUZ.''

        New Zealand UNIX Systems User Group
        P.O. Box 585
        Hamilton
        New Zealand
        [phone]



The Japan UNIX Society has three meetings a year, and a newsletter.
The JUS UNIX Symposium is held twice annually, once in the winter and
once in the summer.  It has technical presentations, tutorials,
and a vendor exhibit.  The JUS UNIX Fair is held once a year, and
has a vendor exhibit, tutorials, and seminars.

        Japan UNIX Society (JUS)
        #505 Towa-Hanzomon Corp. Bldg.
        2-12 Hayabusa-cho
        Chiyoda-ku, Tokyo 102
        Japan
        [e-mail]
        [phone]


1990 Jul 9-11   15th JUS S        JUS, Tokyo, Japan
1990 Nov 15-16  16th JUS S          JUS, Osaka, Japan
1990 Dec 4-5    JUS UNIX Fair '90       JUS, Tokyo, Japan

The Korean UNIX User Group (KUUG) has a software distribution service
and a newsletter.  They hold an annual Korean UNIX Symposium in the winter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Dae Jeon City
        Chungnam 301-350
        Republic of Korea

        Kee Wook Rim
        [e-mail]
        [phone] x4646
        fax: [phone]


The Malaysian Unix Users Association (MALNIX) hold seminars and

                The Organiser
                MALNIX/MIMOS International Seminar
                7th Floor, Bukit Naga Complex
                Jalan Semantan
                50490 Kuala Lumpur, Malaysia
                [phone]
                fax: [phone]
                [e-mail]  or uunet!mimos!malnix

The Singapore UNIX Association (Sinix) holds an annual Southeast Asian
Regional Computer Conference.

        James Clark
        Sinix
        c/o Computer Systems Advisers, Ltd.
        203 Henderson Industrial Park
        Wing B #1207-1214
        Singapore 0315
        [phone]
        fax: [phone]

1990 Dec 10-12  Unix Asia '90 C Sinix, Singapore
1990 Dec 13-16  Unix Pavilion '90 T    Sinix, Singapore

The China UNIX User Group (CUUG) is the Chinese UniForum affiliate.

        Xu Kongshi
        China UNIX User Group
        P.O. Box 8718
        Beijing, 100080
        People's Republic of China
        [phone]


There are similar groups in other parts of the world.  If such a group
wishes to be included in later versions of this access list, they
should please send me information.

There is a partial list of national organizations in the November/December
1987 CommUNIXations.



DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held twice a year.

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        U.S.A.
        [phone]

The next DECUS Symposia are:

1990 Dec 10-14  DECUS         Las Vegas, NV
1990 Sept 3-7    DECUS Euorpe S    Cannes, France
1991 Feb 18-22    DECUS         Ottawa, Canada
1991 May 6-10   DECUS         Atlanta, GA
1991 Dec 9-13   DECUS         Anaheim, CA
1992 May 4-8    DECUS         Atlanta, GA

See also the USENET newsgroup comp.org.decus.


The Sun User Group (SUG) is an international organization that promotes
communication among Sun users, OEMs, third party vendors, and Sun
Microsystems, Inc.  SUG sponsors conferences, collects and distributes
software, produces the README newsletter and T-shirts, sponsors local
user groups, and communicates members' problems to Sun employees and
management.

    Sun Microsystems User Group, Inc.
    2550 Garcia Avenue
    Mountain View, CA  94043
    U.S.A.
    [phone]
    [e-mail]
    sun!users

1990 Sept 20-21 Sun UK User Group    Edinburgh, UK
1990 Dec 3-5    Sun User Group      San Jose, CA
1991 Jun 17-19  Sun User Group      Atlanta, GA
1991 Dec 9-11   Sun User Group      San Jose, CA
1992 Jun 22-24  Sun User Group      Washington, DC

ADUS is the Apollo DOMAIN Users' Society:

    Apollo DOMAIN Users' Society
    c/o Andrea Woloski, ADUS Coordinator
    Apollo Computer Inc.
    330 Billerica Rd.
    Chelmsford, MA 01824
    U.S.A.
    [phone], x4448


Interex, The International Association of HP Computer Users
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held once a year in the
U.S. and Europe.

    Interex
    585 Maude Court
    P.O. Box  3439
    Sunnyvale, California,   94088-3439
    U.S.A.
    [phone]

1990 Aug 20-23    Interex Conference    Boston, MA

The Open Software Foundation (OSF) is a vendor group formed 17 May 1988
by Apollo, Bull, DEC, HP, IBM, Nixdorff, and Siemens, and later joined
by Philips and numerous other companies.

For more information, contact:

    [phone]
    Larry Lytle or Gary McCormack
    Open Software Foundation
    11 Cambridge Center
    Cambridge, MA 02139
    U.S.A.


UNIX International (UI) was formed to advise AT&T on UNIX System V
development.  Its membership includes AT&T, Control Data, Data General,
Fujitsu, Gould, Intel, Interactive, NEC, Sun Microsystems, Texas
Instruments, Unisys, and other companies and institutions.

        UNIX International
        20 Waterview Blvd.
        Parsippany, NJ 07054
    U.S.A.
        [phone]
        800-UI-UNIX-5
        800-848-6495

Volume-Number: Volume 20, Number 13

From [e-mail]  Tue May 22 11:11:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07492; Tue, 22 May 90 11:11:51 -0400
Posted-Date: 22 May 90 14:28:57 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA01537; Tue, 22 May 90 10:11:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03382; Tue, 22 May 90 09:29:34 cdt
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Expires: 1 Jul 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 22 May 90 14:28:57 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne W. Smith)

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX-related publications;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there.

There are three related articles, posted at the same time as this one,
with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Corrections and additions to this article are solicited.  We keep track
of the conferences, groups, and publications that we attend, are members
of, or subscribe to.  All others (the majority of the listings) we derive
either from listings elsewhere, or from contributions by readers.
In particular, the meeting schedules and descriptions of most of the
groups are provided by their members.  If a group doesn't have a
meeting schedule listed, it's because nobody has sent one.  This is
a low-budget operation:  we publish what is on hand when the time
comes (approximately bi-monthly).

Changes since last posting: root & UNIQUE publisher, IX-Magazine,
        UNIGRAM*X, AIX Age, UNIX Technology Advisor

Access information is given in this article for the following:
magazines:    UNIX REVIEW, UNIX/WORLD, UNIX Systems,
        UNIX Today, Multi-User Computing Magazine, UNIX Magazine,
        IX-Magazine, The FourGen UNIX Journal, root,
        Dr. Dobbs Journal of Software Tools, Multi-User Journal
user group publications:
        ;login:, Computing Systems, UniNews, CommUNIXations,
        EUUGN, AUUGN, NUZ,
newsletters:    ExperTips, UNIGRAM*X, UNIX Technology Advisor,
        The C Users Journal, Unique
vendor specific publications:
        AIX Age, AT&T Technical Journal, Sun Expert
video:        UNIX Video Quarterly
bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
        Inside Information, Jim Joyce's UNIX Book Store,
        Uni-OPs Books, UNIX Book Service


The main general circulation (more than 10,000 copies per issue) magazines
specifically about the UNIX system are:

    UNIX REVIEW
    Miller Freeman Publications Co.
    500 Howard Street
    San Francisco, CA 94105
    U.S.A.
    monthly
    [phone]

    UNIX/WORLD
    Tech Valley Publishing
    444 Castro St.
    Mountain View, CA 94041
    U.S.A.
    monthly
    [phone]

    UNIX Systems
    Eaglehead Publishing Ltd.
    Maybury Road
    Woking, Surrey GU21 5HX
    England
    [phone]

    UNIX Today!
    CMP Publications, Inc.
    600 Community Drive
    Manhasset, NY 11030
    U.S.A.
    newspaper
    subscription information: uunet!utoday!evette
        [phone]

    Multi-User Computing magazine
    Storyplace Ltd.
    42 Colebrook Row
    London  N1 8AF
    England
    [phone]

    UNIX Magazine
    Jouji Ohkubo
    c/o ASCII Corp.
    Japan
    [e-mail]
    [phone]
    fax: [phone]
    telex: 242-6875 ASCIIJ

Other related magazines:

    IX-Magazine: Le Magazine de l'informatique partagee
    Publications GRD
    75241 Paris CEDEX 05
    France
    [phone]
    fax: [phone]
    monthly
    special foreign subscription rate of 385 FF (550 FF is normal rate)

    April 1990 issue is about standards.

    The FourGen UNIX Journal
    ``The Monthly Newsletter for those Developing,
      Marketing, or Using UNIX/XENIX Software.''
    FourGen Software, Inc.
    7620 242nd St. S.W.
    Edmonds, WA 98020-5463
    U.S.A.
    $79.95 a year
    [phone]
    uunet!4gen!info

        root, the Journal of UNIX/Xenix System Administration
    Root Creations, Inc.
    632 East Bidwell St., Suite 56
    Folsom, California 95630.
    U.S.A.
        bimonthly

    Dr. Dobbs Journal of Software Tools
    M&T Publishing, Inc
    501 Galveston Dr.
    Redwood City, CA  94063
    U.S.A.
    [phone]
    Mostly DOS, some UNIX, quite technical
    monthly
    $29.97 per year

        Multi-User Journal
        Owens-Laing Publications, Ltd.
        P.O. Box 2409
        Redmond, WA  98073-2409
        [phone]
        attmail!olp!jou
        quarterly
    mostly Sys V-related.  They also publish the
        _3B Journal_ addendum, specializing in the AT&T 3B family.


User group newsletters, magazines, and journals:

The USENIX Association publishes a bimonthly newsletter, ``login:
The USENIX Association Newsletter,'' and a quarterly refereed technical
journal, ``Computing Systems: The Journal of the USENIX Association,''
(in cooperation with University of California Press), and an edition
of the 4.3BSD Manuals (with Howard Press).

    USENIX Association
    2560 Ninth St, Suite 215
    Berkeley, CA 94710
    U.S.A.
    [phone]

UniForum publishes a biweekly newsletter, UniNews, formerly /usr/digest,
a bimonthly member magazine, CommUNIXations, and the
UNIX Products Directory.

    UniForum
    2901 Tasman Drive, Suite 201
    Santa Clara, California 95054
    U.S.A.
    [phone]

EUUG publishes a quarterly magazine, EUUGN.

    EUUG secretariat
    Owles Hall
    Buntingford
    Herts SG9 9PL
    England
    [phone]
    fax: [phone]
    uunet!mcvax!inset!euug
    [e-mail]

AUUG publishes a bimonthly newsletter, AUUGN.

    AUUG
    P.O. Box 366
    Kensington
    N.S.W.    2033
    Australia
    uunet!munnari!auug
    [e-mail]


NZSUGI publishes a newsletter, NUZ.

    New Zealand UNIX Systems User Group
    P.O. Box 585
    Hamilton
    New Zealand
    [phone]


Newsletters:

    ExperTips
    Berkeley Decision/Systems
    803 Pine St.
    Santa Cruz, CA 95062
    U.S.A.
    [phone]
    fax: [phone]
    free

    UNIGRAM*X
    American publisher is Maureen O'Gara
     3 Maple Place
        Glen Head, NY 11545 USA
    U.S.A.
    [phone]
    $495/year

    English publisher is Simon Thompson
    Unigram Products Limited
    4th Floor,
    12 Sutton Row
    London W1V 5FH
    England
    [phone]
    price: ask

    UNIX Technology Advisor
    MYOB, Inc.
    PO Bos 955
    Hollis, NH  03049
    U.S.A.
    [phone]
    monthly
    $295/year

    The C Users Journal
    ``A service of the C Users Group.''
    R&D Publications Inc
    2601 Iowa St., Suite B
    Lawrence, KS  66047
    U.S.A.
    Eight issues per year
    $20/yr (US/Mex/Can); $30/yr (overseas)
    [phone]
    Mainly DOS-oriented; some UNIX.

    Unique
    ``The UNIX System Information Source.''
    R&D Publications Inc
        2601 Iowa St., Suite B
        Lawrence, KS  66047
        U.S.A.
    Monthly
    [phone]
    Emphasis on marketing implications of technical developments.

Vendor-specific newsletters, magazines, and journals:

    AIX Age
    Chuck Balsly
    P.O. Box 153588,
    Irving, Texas USA
    U.S.A.
    [phone]

    AT&T Technical Journal
    AT&T Bell Laboratories
    Circulation Dept.
    Room 1K-424
    101 J F Kennedy Parkway
    Short Hills, NJ 07078
    U.S.A.
    Bimonthly
    $40/yr (US); $50/yr (overseas)
    [phone]
    While few issues are devoted to UNIX,
    most turn out to mention its applications.

        Sun Expert
        Expert Publishing Group
        1330 Beacon Street
        Brookline, MA 02146
    U.S.A.
        uunet!expert!circ ([e-mail])
        [phone]
    Monthly

Videos:
    UNIX Video Quarterly
    InfoPro Systems
    PO Box 220
    Rescue, CA 95672-0220
    U.S.A.
    [phone]
    Telex: 151296379 INFOPRO
    fax: [phone]
    {ames,attmail,pyramid}!infopro!root
    VHS. The first tape (1 hr. 18 min.) is now available.
    Charter subscriptions $195/year.


Some of the following information about bookstores was taken from the
November/December 1987 issue of CommUNIXations.  The remainder was
submitted by different readers of this list.  In the interests of
space, we have arbitrarily limited the selection listed here to those
bookstores or suppliers specifically dedicated to computer books, and
not part of other organizations.  They are listed here in alphabetical
order.

    Computer Literacy Bookshop
    2590 No. First St.
    San Jose, CA 95131
    U.S.A.
    [phone]

    Cucumber Bookshop
    5611 Kraft Ave.
    Rockville, MD 20852
    U.S.A.
    [phone]

    Inside Information
    77 Harbord Street
    Toronto, Ontario M5S 1G4
    Canada
    [phone]

    Jim Joyce's UNIX Book Store
    139 Noe St.
    San Francisco, CA 94114
    U.S.A.
    [phone]
    [e-mail]

    Uni-OPs Books
    195 Mt. View Rd.
    Boonville, CA 95415
    U.S.A.
    [phone]

    UNIX Book Service
    35 Bermuda Terrace
    Cambridge, CB4 3LD
    England
    [phone]

Volume-Number: Volume 15, Number 24


Volume-Number: Volume 20, Number 14

From [e-mail]  Tue May 22 11:13:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07819; Tue, 22 May 90 11:13:30 -0400
Posted-Date: 22 May 90 14:33:34 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA01715; Tue, 22 May 90 10:13:11 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03442; Tue, 22 May 90 09:34:14 cdt
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 1 Jul 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 22 May 90 14:33:34 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne W. Smith)

This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.

There are three companion articles, posted at the same time as this one
with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Also note that Jeff Haemer now writes a quarterly summary report for
USENIX soon after each IEEE 1003 meeting for posting in comp.std.unix
and in ;login:, the Newsletter of the USENIX Association.

Changes since last posting: IEEE/CS P1003 contacts, groups, dates,
    NIST, UniForum working groups.

Access information is given in this article for the following standards:
ISO/IEC TC1 SC22 WG15 (POSIX)
ISO/IEC TC1 SC22 WG14 (C language)
IEEE     1003.0  (POSIX guide).
    1003.1  (operating system interface),
     1003.2  (shell and tools),
    1003.3  (testing and verification),
    1003.4  (real time),
    1003.5  (ADA binding),
    1003.6  (security),
    1003.7  (system administration),
    1003.8  (transparent file access),
    1003.9  (FORTRAN binding),
    1003.10 (supercomputing),
    1003.11 (transaction processing),
    1003.12 (protocol independent interfaces)
    1003.13 (name space/directory services)
    1003.14 (Real Time)
    1003.16 (multiprocessing study group)
    1003.17 (supercomputing batch element)
    1201.1  (interfaces for user portability)
    1201.2  (recommende practice on drivability)
    1224    (message handling services)
    1237    (RPC)
    1238.1  (Common OSI API)
    1238.2  (FTAM)
UniForum Technical Committee Subcommittees on;
    distributed file system,
    network interface,
    internationalization,
    realtime,
    database,
    performance measurements,
    security,
    super computing,
    usability,
    transaction processing, and
    C++.
NIST:  FIPS
X3H3.6 (display committee)
X3J11 (C language)
/usr/group 1984 Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE
4.3BSD Manuals

UNIX is a Registered Trademark of AT&T.
IEEE is a trademark
    of the Institute of Electrical and Electronic Engineers, Inc.
POSIX is no longer a trademark of IEEE or of anyone else.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee.  They published the 1003.1 "POSIX" Full Use
Standard in October 1988 after its formal approval 22 August 1988.
This is an interface and environment standard; implementation details
are explicitly excluded.  Although it is based on documentation for
various versions of the UNIX Operating System, it is explicitly not
UNIX, which is an implementation licensed by a certain vendor.  Source
level application portability is the goal.

The standard may be ordered from:

        [phone]
        IEEE Service Center
        445 Hoes Lane
        Piscataway, NJ  08854
        U.S.A.

The price is $16 for members, $32 for non-members (plus $4.00 tax,
shipping, and handling).

Single copies of current drafts of the 1003 documents can be obtained
from the Computer Society with a charge to cover reproduction and mailing.
Their phone number is [phone].

IEEE 1003.1 is also an ``International Standard (IS 9945-1)''
under a joint committee of the International Organization for Standardization
(ISO) and the International Electrotechnical Committee (IEC), Joint
Technical Committee 1, Subcommittee 22, Working Group 15 (ISO/IEC JTC1
SC22 WG15).  The convener is Jim Isaak:  see below for his address.
Dominic Dunlop is the EUUG and USENIX representative to ISO/IEC JTC1 SC22 WG15
and WG14. There is a U.S. Technical Advisory Group (TAG) to
ISO/IEC JTC1 SC22 WG15: the chair is Donn Terry of HP, who is also the
current chair of IEEE 1003.1.

        Donn Terry
        hplabs!hpfcla!donn
        [phone]
        Hewlett Packard Systems Division
        3404 E. Harmony Road
        Fort Collins, CO  80525
        U.S.A.

TAG meetings tend to be held wherever 1003.1 is meeting.


There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        [phone]
        fax: [phone]
        [e-mail]
        [e-mail]
        Digital Equipment TTB1-5/G06
        10 Tara Blvd.
        Nashua, NH  03062
        U.S.A.

Sufficiently interested parties may join the working group.


The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                chairs, vice-chair
1003.0    POSIX Guide            Al Hankinson (NIST)
                    [e-mail]
                    Kevin Lewis (DEC)

1003.1    Systems Interface        Donn Terry (HP)
                    hplabs!hpfcla!donn

1003.2    Shell and Tools Interface      Hal Jespersen (POSIX Software Group)
                    uunet!posix!hlj
                    Don Cragun (Sun)
                    [e-mail]

1003.3    Verification and Testing     Roger Martin (NIST)
                    [e-mail]
                    N. Ray Wilkes (UNISYS)
                    nrw@sp7040

1003.4    Real Time             Bill Corwin (Intel)
                    uunet!littlei!wmc
                    Mike Cossey

1003.5    Ada Binding for POSIX        Steven Deller (Verdix)
                    [e-mail]
                    Terry Fong (USArmy)
                    [e-mail]

1003.6    Security            Dennis Steinauer (NIST)
                    [e-mail]
                    Ron Elliot (IBM)
                    [e-mail]

1003.7    System Administration        Steve Carter (Bellcore)
                    bellcore!pyuxv!slc2
                    David Hinnant (BNR)
                    uunet!rti.rti.org!bnrunix!dfh
                    Martin Kirk (BTRL)
                    ukc!axion!mkirk

Distributed Services Steering Committee    Timothy Baker (Ford Aero)
                    [e-mail]
                    Dave Dodge
                    hplabs!oracle!ddodge

1003.8    TFA SG                Jason Zions (HP)
                    [e-mail]
1003.12 Protocol Independent Interfaces Les Wibberley (Chemical Abstracts)
                    [e-mail]
1003.13    Name Space/Directory Services     Lakshmi Arunachalam (Sun)
1237    RPC                 Ken Hobday (DEC)
1238.1    Common OSI API             Kester Fong (GM)
1238.2    FTAM SG
1224    Message Handling Services (X.400) SG
                    John Boebinger (DEC)

1003.9    Fortran Bindings        John McGrory (HP)
                    [e-mail]
                    Michael J. Hannah (Sandia)
                    [e-mail]

1003.10    Supercomputing SG        Karen Sheaffer (Sandia)
                    [e-mail]
                    Jonathan C. Brown (Lawrence Livermore)
                    [e-mail]

1003.11    Transaction Processing SG    Elliot J Brebner (Unisys)
                    uunet!s5000!brebner
                    Bob Snead (Interactive)
                    [e-mail]

1003.14 Real Time AEP             see 1003.4

1003.16 Multiprocessing Study Group

1003.17 SC Batch element

1201.1  Interfaces for User Portability    Sunil Mehta (Convergent),
1201.2     Recommended Practice on Drivability
                     Lin Brown (Sun)
                    [e-mail]@Sun.COM


Inquiries regarding any of the subcommittees should go to the address for the
IEEE 1003 chair.

The next scheduled meetings of the P1003 working groups are:

1990 Jul 16-20    IEEE 1003    Danvers, MA
1990 Oct 15-19    IEEE 1003    Seattle, WA
1991 Jan 7-11    IEEE 1003    New Orleans, LA
1991 Apr 15-19    IEEE 1003    Houston, TX (location tentative)
1991 July 8-12    IEEE 1003    Santa Clara, CA (location tentative)
1991 Oct 21-25    IEEE 1003    Southern Europe (location tentative)
1992 Jan 13-17    IEEE 1003    Orlando, FL (location tentative)
1992 Apr 20-24    IEEE 1003    Montreal, PQ (location tentative)
1992 Jul 13-17    IEEE 1003    Alaska (location tentative)
1992 Oct 19-23    IEEE 1003    Scottsdale, AZ (location tentative)

There are seven Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama and Ralph Barker from UniForum, Petr Janecek
from X/OPEN, Fritz Schulz from OSF, Shane McCarron from UNIX International,
and Richard Alexander from Share.  They are apparently all also representatives
to the U.S. TAG to ISO SC22 WG15.

There is a USENIX Standards Watchdog Committee of volunteers who report
on issues raised in standards committee meetings.  These reports are
published quarterly in comp.std.unix, in ;login: The Newsletter of the
USENIX Association, and in the trade press.  Occasionally, these volunteers
may speak for USENIX, but only if authorized by the USENIX Standards
Policy Committee, which currently consists of John S. Quarterman (chair),
Marshall Kirk McKusick (USENIX President), Alan G. Nemeth (former USENIX
President), and Ellie Young (USENIX Executive Director).

Comments, suggestions, etc., may be sent to


        John S. Quarterman
        USENIX Standards Liaison
        Texas Internet Consulting
        701 Brazos, Suite 500
        Austin TX 78701-3243
        [phone]
        fax: [phone]
        [e-mail]
        uunet!usenix!jsq


For comp.std.unix:
Comments:       uunet!std-unix-request  [e-mail]
Submissions:    uunet!std-unix          [e-mail]

CommUNIXations (the UniForum magazine) contains reports about every
other issue by Allen Hankinson on the UniForum Technical Committee meetings.

If you are interested in starting another UniForum working group, contact
Allen Hankinson:

        Allen L. Hankinson
        National Institute of Standards & Technology
        Systems & Software Technology Div.
        Tech Building, Room B266
        Gaithersburg, MD  20899
        [phone]
        fax: [phone]
        [e-mail]


Here is contact information for UniForum working groups.

UniForum Working Group on Internationalization:
    Loretta Goudie
    Santa Cruz Operation
    400 Encinal
    Santa Cruz, CA 95060
    408-458-1422

UniForum Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

UniForum Working Group on Performance Measurements:
    Ram Chelluri
    AT&T Computer Systems
    Room E15B
    4513 Western Ave.
    Lisle, IL 60532-1571
    [phone]

UniForum Working Group on Security:
    Jeanne Baccash
    AT&T UNIX Systems Engineering
    190 River Road
    MS G-222
    Summit, NJ  07901
    201-522-6028
    attunix!jeanne

UniForum Working Group on C++:
    Don Kretsch
        AT&T Information Systems
        190 River Road
    Summit, NJ  07901
    201-522-6499


The National Institute of Standards and Technology (NIST, formerly NBS,
the National Bureau of Standards) has produced a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1 Draft 12, and approved
31 August 1988 as FIPS #151, Portable Operating System for Computer
Environments.  An update to the state of the 1003.1 Full Use Standard
is expected.  For information, contact:

        Roger Martin
        National Institute of Standards and Technology
        Technology Building, Room B266
        Gaithersburg, MD 20899
            [phone]
            [e-mail]

NIST has a POSIX Conformance Test Suite (PCTS) for 1003.1 which is
currently in preliminary external testing.

NIST is also producing a FIPS based on IEEE 1003.2, and has started
one on system administration.

NIST sponsors a number of standards-related workshops, including:

1990 Nov 15    APP/OSE Users Forum    NIST, G, MD
1991 May 9    APP/OSE Users Forum    NIST, G, MD
1991 Nov 14    APP/OSE Users Forum    NIST, G, MD


The X3H3.6 display management committee is in the final stages of
standardization of the X Window System Data Stream Encoding Version 11
(the "X Protocol"). They will soon begin the standardization of Xlib
and its various language bindings (C, ADA, Fortran) as well as begin
the standardization process within ISO.  The chair is

        Dr. Georges Grinstein
        [e-mail]



X3J11 is sometimes known as the C Standards Committee.  Their liaison
to P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

ANSI documents may be ordered from

        Global Engineering Documents
        2805 McGaw
        Irvine, CA 92714
        USA
        [phone]
        [phone]

As of May 21, 1990 only the X3.159-1988 draft is available and the price
is $70. When available the standard document will be X3.159-1990.

The /usr/group 1984 Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        UniForum Standards Committee
        2901 Tasman Drive, Suite 201
        Santa Clara, California 95054
        Tel: [phone]
        Fax: [phone]

UniForum also publishes the documents, ``Your Guide to POSIX,''
explaining what IEEE 1003 is,  ``POSIX Explored: System Interface,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations, and ``POSIX Update: Shell and Utilities.''
Contact UniForum at the above address for details.


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        [phone] (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The implementation of System V is described in the book

    The Design of the UNIX Operating System
    Maurice J. Bach
    Prentice-Hall, Englewood Cliffs, New Jersey


The X/Open Portability Guide (XPG) is another reference frequently
used by IEEE 1003.

The X/Open Group was formed by "Ten of the world's major information system
suppliers". The number of member companies has grown since then.
They have produced a document intended to promote
the writing of portable applications.  They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.

The books are published by

        Prentice-Hall
        Englewood Cliffs
        New Jersey  07632

There are currently seven volumes:
    1) XSI Commands and Utilities
    2) XSI System Interface and Headers
    3) XSI Supplementary Definitions
    4) Programming Languages
    5) Data Management
    6) Window Management
    7) Networking Services

    All 7 Volumes

Comments, suggestions, error reports, etc., for Issue 3 of the X/OPEN
Portability Guide may be mailed directly to:

        [e-mail]
        uunet!mcvax!inset!xopen!xpg3

Information about X/OPEN can be requested from:

        Mike Lambert
        X/Open
        Apex Plaza,
        Forbury Road
        Reading
        Berkshire RG1 1AX
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:

        Howard Press
        c/o USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710

        [phone]
        uunet!usenix!office
        [e-mail]

4.3BSD User's Manual Set (3 volumes)        $25.00
    User's Reference Manual
    User's Supplementary Documents
    Master Index

4.3BSD Programmer's Manual Set (3 volumes)    $25.00
    Programmer's Reference Maual
    Programmer's Supplementary Documents, Volume 1
    Programmer's Supplementary Documents, Volume 2

4.3BSD System Manager's Manual (1 volume)    $10.00

Unfortunately, there are some license restrictions.
Contact the USENIX office for details.


Information about the design and implementation of 4.3BSD can be found
in the book

    The Design and Implementation of the 4.3 BSD UNIX Operating System
    Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, and
        John S. Quarterman
    Addison-Wesley, Reading, Massachusetts, 1989

Volume-Number: Volume 20, Number 15

From [e-mail]  Wed May 30 02:10:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11945; Wed, 30 May 90 02:10:25 -0400
Posted-Date: 22 May 90 17:56:11 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA16308; Wed, 30 May 90 01:10:19 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13094; Tue, 29 May 90 22:59:48 cdt
From: Peter da Silva <ficc.ferranti.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 22 May 90 17:56:11 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

[ in the real world there are programmers who aren always as sensitive
  to portability issues as they should be ]

> I like to think I'm working in the real world, and because I do care
> about application portability I'm careful about these things when I
> program.  I suspect I'm not the only one.

You and I will do that. But the people whose code I find myself maintaining
are not always quite so careful. They generally try to conform to the
standard as far as they know it, but aren't willing to go back to the base
document to check on stuff they're sure is correct.

> Note that there IS no magic
> road to guaranteed portability, if the programmer is oblivious to the
> issues.

Not oblivious. Just not as sensitive as they should be. Say, someone trying
to maintain a program that uses mmap(). Suddenly they need to save state,
so they put the arguments in to map the whole file in. Six months later,
when time comes to integrate this code back to the baseline it breaks on
some machine that doesn't have a real mmap().

I don't want a magic road, but the signposts should at least be clear.

[ extensions should require some magic juju before they're active, like
  calling mmap instead of shmmap ]
> That would be nice, but it's pretty hard to enforce in cases like
> adding extended functionality to the standard functions.

Such as?
--
`-_-' Peter da Silva. [phone].  <[e-mail]>
 'U`  Have you hugged your wolf today?  <[e-mail]>
@FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.


Volume-Number: Volume 20, Number 15

From [e-mail]  Wed May 30 02:10:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11982; Wed, 30 May 90 02:10:38 -0400
Posted-Date: 23 May 90 16:31:58 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA16327; Wed, 30 May 90 01:10:31 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13166; Tue, 29 May 90 23:05:38 cdt
From: Mike Schultz <oakhill.sps.mot.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mike Schultz)
Organization: Motorola Inc., Austin, Texas
Date: 23 May 90 16:31:58 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Mike Schultz)

In article <[e-mail]> From:  [e-mail]
>In article <[e-mail]> [Doug Gwyn] writes:
>>Like calling mmap() instead of whatever the POSIX routine is.
>
>I hope we don't have to name a new interface every time a new standard
>restricts or changes the syntax of an old one.  Especially when the
>old interface is difficult to use portably anyway.

I can't tell if you are for or against the use of the new interface,
especially with the comment about the "difficult to use portably anyway"
comment.

The reason that the new interface was choosen is this:

For REAL TIME purposes, shared memory functionality  is very useful, but
REQUIRING it to map files would be unacceptable for many implementations.  Even
the suggestion that the file would be on a RAM disk is not acceptable.  The
application should be able to request the shared memory to be mapped in
and that is the LAST thing that the operating system should HAVE to do with
it.

Thus P1003.4 needed an interface that did not require that files be mapped.
Mmap was existing practice, but it would have to be gutted in order to
used it.  It was felt that there was two courses to take here, both of which
was certain to draw ballot objections.

The solution choosen was one that was a subset of mmap's functionality, but
was not the same interface.  This had two advantages:  First, it could be
implemented with mmap using macros.  Second, if an implementation wished
to contain a pure shared memory interface, without routing it thru the
blasted file system, it could do that as well as implementing mmap.

Anyway, that was the reasoning then.

Now here are the latest developments.  SVR4 has taken the step of implementing
mmap without requiring it to be a file.  It states that one is mapping in
a virtual memory object instead.  It may be possible for the SVR4 wording of
mmap to be used as existing practice.  There will have to be some functionality
labeled as implementation defined.

We'll see how it goes.

Mike Schultz
[e-mail]

And soon to be

[e-mail]

Volume-Number: Volume 20, Number 16

From [e-mail]  Wed May 30 02:10:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12041; Wed, 30 May 90 02:10:49 -0400
Posted-Date: 23 May 90 18:00:57 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA16338; Wed, 30 May 90 01:10:42 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13224; Tue, 29 May 90 23:08:24 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Tape Driver standards?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 23 May 90 18:00:57 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>I am interested in finding out the current state of standards efforts
>in regards to tape drivers, specifically:
>
>Is there any standard ioctl interface to take advantage of the flexibility
>afforded by the SCSI interface?

There's a *de facto* semi-standard (as in "there are probably retrograde
systems that do it differently but no better, and are definitely systems
that don't do it at all"), namely the "ioctl"s provided by 4.xBSD.  They
don't "take advantage of the flexibility afforded by the SCSI interface"
in the sense that they let you do stuff that works only on SCSI tapes;
the "ioctl"s include one to perform "special functions", including
spacing forwards and backwards by files and by blocks, rewinding,
rewind-and-unload, etc., but you can do those on non-SCSI tape drives as
well.

>I have heard rumors that AT&T has come up with a proposal (or perhaps a
>de-facto standard in SVR4), but don't have any details.  Can anyone
>supply me with some?

All I know of is that AT&T provides, in the "Berkeley compatibility"
package, the 4.xBSD (or maybe SunOS 4.x, derived from 4.xBSD) "mt"
command, and it probably uses the BSD "ioctl"s.  They provide
<sys/mtio.h> (the include file that defines those "ioctl"s, and the
commands they perform and data structures they use), but only as part of
the compatibility package, not as an official part of S5R4.  In fact,
the S5R4 "BSD/XENIX(R) Compatibility Guide" says, about the "mt"
command:

    Both rely in a set of "ioctl"s that are not present in default
    UNIX System V.  However, users with new or enhanced device
    drivers may take advantage of this command.

Which means that, if you want to provide them with your S5 port, you can
do so; if you're going to provide "ioctl"s of that sort, it's probably
best to provide the BSD ones or ones based on them.

>Is there any standard action for what a tape driver should do with
>internal flags (End-Of-Media, Filemark, etc.) when it receives an ioctl
>call (like, clear the "DataWritten" flag so filemark writing won't be
>performed after an ioctl)?

No official one; the drivers I know of tend to clear the "data written"
flag after repositioning the tape.

>Is there any standard defined for what drivers should do with the
>bp->b_blkno?  Early AT&T drivers (the Kennedy tape drive?) would
>support block device IO to tapes, and would space the requested number
>of 512-byte blocks if the b_blkno didn't match the driver's idea of
>where it was.  So what happens with, say, 5K blocks on a 1/2" tape
>reel?  Or should the driver just ignore the bp->b_blkno field
>altogether?

Some drivers use it, some ignore it.  I wouldn't go out of my way to pay
attention to it; it makes the driver more complicated and, given the
problem you note, and the fact that most of the mag tape use I'm
familiar with involves programs that don't seek around the tape, and the
fact that seeking on mag tapes is generally rather slow, I doubt it
actually makes life any better if the driver *does* try to pretend that
"lseek()" works on a mag tape.

Another disadvantage of the block device is that it has to pick some
arbitrary block size; said block size may not match the block size on
the tape (unless you're talking tapes like QIC tapes with a standard
block size), and may also be smaller than you'd like (512-byte blocks,
which are the default, at least in most non-4.[23]BSD systems, are
rather silly on 1/2" tapes, for instance).

>These questions are prompted by the infamous exabyte tape drive.

The BSD "ioctl"s long antedate Exabytes; they apply to all tapes, and
make life nicer on all tapes.

Volume-Number: Volume 20, Number 17

From [e-mail]  Wed May 30 02:11:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12105; Wed, 30 May 90 02:11:01 -0400
Posted-Date: 23 May 90 18:59:25 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA16346; Wed, 30 May 90 01:10:55 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13295; Tue, 29 May 90 23:12:45 cdt
From: Susanne Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Calendar of UNIX-related Events (NLUUG date)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Susanne Smith)
Date: 23 May 90 18:59:25 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne Smith)

In the recent access postings the date for the Open Systems Conference
sponsored by the Netherlands UNIX Users Group (NLUUG) is wrong.
The correct information is:

1990 Nov 1      Open Systems C  NLUUG, Ede, Netherlands

Volume-Number: Volume 20, Number 18

From [e-mail]  Wed May 30 02:11:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12244; Wed, 30 May 90 02:11:11 -0400
Posted-Date: 24 May 90 20:54:51 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA16363; Wed, 30 May 90 01:11:05 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13468; Tue, 29 May 90 23:26:31 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX User Groups
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 24 May 90 20:54:51 GMT
Apparently-To: [e-mail]

From:  frith.egr.msu.edu!upba!tssi!nolan

Add to your list the following:

NUUG - NCR Unix User Group, Inc. (yeah, I know, the initials create a duplicate)
       C/O Ritter Food Corporation
       PO Box 216
       Elizabeth, NJ  07207

       President:  John Linden   201-558-2700 x2770

       Annual dues, $50.

Annual Conference(s):
       1990 - October 25-26, Columbia, South Carolina



NUUG is now a member of the Federation of NCR User Groups   (FNUG)

FNUG Address:  Federation of NCR User Groups
               Mail Station USG-1
               Dayton, Ohio  45479

Annual Conference(s):
       1990 - October 28-30, Raleigh, South Carolina   (devoted to unix)
       1991 - (late april), San Antonio, Texas         (some sessions on unix)

(If you detect some ambivalence about the scheduling of two conferences
on unix by related groups about 100 miles apart and separated by 1 day, you
aren't the only one! ;-)
------------------------------------------------------------------------------
Mike Nolan  (NUUG Board Member)                  "I don't know what apathy is,
Tailored Software Services, Inc.                  and I don't want to find out!"
Lincoln, Nebraska [phone]
UUCP: tssi!nolan should work,
      if not try something like uunet!frith!upba!tssi!nolan


Volume-Number: Volume 20, Number 19

From [e-mail]  Wed May 30 02:16:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13855; Wed, 30 May 90 02:16:51 -0400
Posted-Date: 28 May 90 14:02:56 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA16757; Wed, 30 May 90 01:16:47 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13804; Tue, 29 May 90 23:54:55 cdt
From: Andy Tanenbaum <cs.vu.nl![e-mail]>
Newsgroups: comp.std.unix
Subject: ANSI vs POSIX on <sys/types.h>
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: 28 May 90 14:02:56 GMT
Apparently-To: [e-mail]

From:  Andy Tanenbaum <[e-mail]>

We have gone through this before, but I still haven't gotten an unambiguous
answer.  Let me try a specific example to make it clearer.

Suppose you want to write a routine raise() that is ANSI conformant and also
POSIX conformant.  Raise calls the POSIX kill function, so it includes
<signal.h>.  The <signal.h> header contains the prototype for kill(), which
uses pid_t, a type defined in <sys/types.h>.  POSIX mandates <sys/types.h>
but ANSI does not require it.  Thus it is probably not ANSI-legal to put

#include <sys/types.h>

in raise(), since an ANSI routine cannot depend on something that ANSI
doesn't require.  The raise routine would not be portable then, and maybe
not even conformant.  On the other hand, putting the #include in <signal.h>
probably isn't legal either, and certainly not portable to non POSIX
systems.

The question is: it has to go somewhere, but where?  I have thought about
putting it in <signal.h> but protected by #ifdef _POSIX_SOURCE, just as
the prototype for kill is.  However, our earlier discussion in this group
suggested that this wasn't legal either.  Does anybody know what the story
is?

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 20, Number 20

From [e-mail]  Wed May 30 14:08:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13414; Wed, 30 May 90 14:08:52 -0400
Posted-Date: 30 May 90 12:13:38 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA04701; Wed, 30 May 90 13:08:46 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA15062; Wed, 30 May 90 12:31:59 cdt
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ANSI vs POSIX on <sys/types.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 30 May 90 12:13:38 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> Andy Tanenbaum <[e-mail]> writes:
>We have gone through this before, but I still haven't gotten an unambiguous
>answer.  Let me try a specific example to make it clearer.

I'm sure I've given unambiguous answers.
The rules are really quite clear and simple.

>Suppose you want to write a routine raise() that is ANSI conformant and also
>POSIX conformant.  Raise calls the POSIX kill function, so it includes
><signal.h>.  The <signal.h> header contains the prototype for kill(), which
>uses pid_t, a type defined in <sys/types.h>.  POSIX mandates <sys/types.h>
>but ANSI does not require it.  Thus it is probably not ANSI-legal to put
>#include <sys/types.h>
>in raise(), since an ANSI routine cannot depend on something that ANSI
>doesn't require.  The raise routine would not be portable then, and maybe
>not even conformant.  On the other hand, putting the #include in <signal.h>
>probably isn't legal either, and certainly not portable to non POSIX
>systems.
>The question is: it has to go somewhere, but where?  I have thought about
>putting it in <signal.h> but protected by #ifdef _POSIX_SOURCE, just as
>the prototype for kill is.  However, our earlier discussion in this group
>suggested that this wasn't legal either.  Does anybody know what the story
>is?

The above description makes no sense.  The run-time code for raise
does not "include <signal.h>".  In fact, it must not even (in a
conventional linkage environment) invoke the POSIX kill() function,
because the external identifier "kill" is not in the name space
reserved for ANSI C implementations (and thus is reserved for use
by programs, with perhaps totally non-POSIX meaning).  It could,
however, invoke a function named "_kill" or some other such name
reserved for use by implementations.

<signal.h> must not define extra garbage such as the kill() interface
or the POSIX *_t typedefs, except under control of some "feature test
macro" such as _POSIX_SOURCE.  In the case of the typedefs, I would
urge that they not be defined as a side effect of #including <signal.h>
even in the presence of _POSIX_SOURCE.  You don't need pid_t to properly
declare getpid() or kill() in an implementation; instead, simply use the
equivalent type derived from basic types (in this case, probably "int").
Note that this is essential also for the ANSI C declaration of vprintf()
in <stdio.h>, since the va_* identifiers must NOT be defined as a side
effect of #including <stdio.h>, so the implementation of <stdio.h> must
not #include <stdarg.h>.

On the other hand, the implementation of an ANSI C library routine can
certainly depend on things not mentioned in the C standard, such as
for example _kill() and <sys/types.h>.  The following is valid source
code to implement ANSI C conformant raise() in a hypothetical POSIX
implementation:

/*
    raise() -- send a signal to the current process

    public-domain implementation

    last edit:    16-Jan-1990    [e-mail]

    complies with the following standards:
        ANSI X3.159-1989
        IEEE Std 1003.1-1988
        SVID Issue 3
 */
#define    getpid    _getpid            /* required support for ANSI C */
#define    kill    _kill            /* required support for ANSI C */

#include    <sys/types.h>        /* for pid_t */

extern pid_t    getpid();        /* UNIX/POSIX system call */
extern int    kill();            /* UNIX/POSIX system call */

int
raise(sig)
    int    sig;
    {
    return kill(getpid(), sig);    /* set errno to EINVAL if sig invalid */
    }

Volume-Number: Volume 20, Number 21

From [e-mail]  Sun Jun  3 17:25:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29512; Sun, 3 Jun 90 17:25:51 -0400
Posted-Date: 3 Jun 90 21:21:41 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA09943; Sun, 3 Jun 90 16:25:48 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA20945; Sun, 3 Jun 90 16:22:16 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration, Interoperability Subgroup
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jun 90 21:21:41 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX<=-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration, Interoperability Subgroup

Jim R. Oldroyd <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

POSIX has given P1003.7 a charter to define both command-line and
applications-programming interfaces for administering multiple,
networked machines from a central point.  Most reports on this group
seem to focus on the group's object-oriented approach: the
administerable classes the group is defining, their attributes
(properties) and their operators.  [Editor: Martin Kirk has promised
us a report on this.  Watch for it soon.]

Sometimes overlooked in this object-oriented frenzy is another,
equally important, and perhaps more difficult goal of the group:
interoperability.

Imagine, for example, an administrator who wishes to execute an
operation on some fraction of nodes in a large, heterogeneous network
of POSIX systems.  The administrator wants to be able to issue the
request once --  and at his or her own terminal.  The system should
take care of determining which actual objects are affected and of
communicating the request to them.

How should this be done?  The fact that today's networks are
heterogeneous means that it is not sufficient for vendors simply to
supply systems with a consistent set of administerable object classes.
Nor is it enough for vendors to define a consistent set of commands
and API names that operate on these classes.  On top of this, there
has to be a consistent language for systems from different vendors to
communicate with each other in order to tell each other that changes
have to be made to some of the objects they are supporting.

The P1003.7 Interoperability subgroup is defining a standard protocol
for communication with remote objects.

Currently, we are trying to work out the protocol's requirements.  The
protocol will have to support varied system-management philosophies.

__________

 => UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 IEEEd1003.7:dSystem Administration, Interoperability Subgroup


                                - 2 -

Some operations, such as re-enabling all PostScript<= printers, should
be queued and executed independently for each target.  Failure to
enable one printer does not mean that the other printers should remain
disabled.  Others operations must be atomic over the domain, for
example, when adding a user to a set of machines, it is necessary to
confirm that a UID is available on all target machines before adding
the user to any machine.

Each of these problems saddles the protocol with a different
requirement.  The former case could be handled by broadcasting an
instruction and collecting success or failure reports later; the
latter requires a two-phase commit, requesting confirmation that
successful completion is possible throughout the domain before
actually mandating the change.

Do we have to invent a new protocol from scratch?  P1003.7 is actively
studying existing protocols, such as ISO's CMIP/CMIS and the Internet
SNMP.  Both of these are existing protocols designed to manage objects
across multiple systems -- exactly as per P1003.7's needs.  However,
both of these are actually designed to manage the network itself, and
it is not clear that they lend themselves to management of things like
users, printers and filesystems (etc.) properly.  We hope to discover
whether some existing protocol will fill the bill in the next few
meetings.

The Interoperability subgroup of P1003.7 will continue work in this
area at our next meeting (Danvers, MA, July 16-20).  If you are an
interested party, we want to hear from you.

__________

 => PostScript is a trademark of Adobe Systems, Inc.

May 1990 IEEEd1003.7:dSystem Administration, Interoperability Subgroup

Volume-Number: Volume 20, Number 22

From [e-mail]  Sun Jun  3 18:26:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13468; Sun, 3 Jun 90 18:26:02 -0400
Posted-Date: 1 Jun 90 15:45:20 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA12175; Sun, 3 Jun 90 17:25:59 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA21565; Sun, 3 Jun 90 17:39:08 cdt
From: Andy Tanenbaum <cs.vu.nl![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ANSI vs POSIX on <sys/types.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: 1 Jun 90 15:45:20 GMT
Apparently-To: [e-mail]

From:  Andy Tanenbaum <[e-mail]>

In article <[e-mail]> Doug Gwyn <[e-mail]> writes:
><signal.h> must not define extra garbage such as the kill() interface
>or the POSIX *_t typedefs, except under control of some "feature test
>macro" such as _POSIX_SOURCE.  In the case of the typedefs, I would
>urge that they not be defined as a side effect of #including <signal.h>
>even in the presence of _POSIX_SOURCE.  You don't need pid_t to properly
>declare getpid() or kill() in an implementation; instead, simply use the
>equivalent type derived from basic types (in this case, probably "int").

POSIX specifically defines kill's first argument as type pid_t, so it
would seem to be poor programming practice to use int, even if this is legal.
If one replaced the *_t types by their definitions everywhere, then a
decision to change pid_t from, say, int, to, say, long, would require
a real expert to dig through all the code to find those int's that really
are pid_t's.  Maintenance of such code would be exceedingly difficult.
I think that the only realistic way is to use pid_t in the prototype of
kill.  This prototype is required in <signal.h> (protected by
#ifdef _POSIX_SOURCE).

This then raises the question of how to make pid_t known.  In the example
implementation given, <sys/types.h> is included in raise.c.  If this is
indeed legal, then that is clearly one way to do it, as presumably all the
names introduced by <sys/types.h> are not present in the object file,
raise.o, and thus do not pollute the name space.

However, why do you urge not to put #include <sys/types.h> into <signal.h>
under protection of #ifdef _POSIX_SOURCE?

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 20, Number 23

From [e-mail]  Tue Jun  5 15:22:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22463; Tue, 5 Jun 90 15:22:41 -0400
Posted-Date: 1 Jun 90 12:55:40 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA00316; Tue, 5 Jun 90 14:22:33 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA26801; Tue, 5 Jun 90 14:37:28 cdt
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Changes in IEEE Standards Numbers
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Jun 90 12:55:40 GMT
Apparently-To: [e-mail]

From: John S. Quarterman <[e-mail]>

The IEEE Computer Society Technical Committee on Operating Systems
(IEEE/CS TCOS) is the group that sponsors the IEEE 1003 (POSIX),
IEEE 1201, etc. standards committees related to the UNIX operating
system.  TCOS (in the form of its Standards Executive Committee, or SEC)
recently approved a number of requests for work on new documents or for
the formation of new committees, as has been reported previously in
this newsgroup.

These Project Authorization Requests (PARs) then had to be approved by
the IEEE Standards Board (SB), which met a few weeks ago.  The SB
usually approves everything TCOS sends them, and in fact did so this
time.  However, they changed many of the characteristic numbers that
identify the committees from the numbers that were proposed in the PARs
and sent to SB by TCOS, and they also changed some of the titles slightly.

Some sort of revised compendium of the current TCOS-sponsored committees
will appear in this newsgroup soon, but in the meantime, here is a brief
list of the specific changes.  The appended information comes from Jim Isaak,
IEEE/CS TCOS Chair.

John S. Quarterman <[e-mail]>
Institutional Representative from USENIX to IEEE/CS TCOS.


1003.1a is now 1003.1 (a revision of a standard, takes on the full number)

1003.1b is now 1003.1a (because of the elevation of the above item)

1003.4b is a revision of 1003.4, and as such is a NEW PAR for 1003.4 !!

1003.4c is now 1003.4b (because of the elevation of the above item)

without a .13 and .15, all those numbered higher have been advanced:

1003.14 is now 1003.13 (Bill Corwin gets the lucky number)

1003.16 is now 1003.14 (Bob Knighten & co)

1003.17 is now 1003.15 (Batch for SC)

1238.1 is 1238 (foundation document)
1238.2 is now 1238.1 (dependent document)

title of 1003.2 has had "Part 2:" added (we dropped it by mistake in my office)

title of 1238 documents has had "PART #" removed in both cases.

title of 1237 is now .... Application Program Interface for RPC.

Title of 1003.2a has a comma added "shell and utilities, ..."

Volume-Number: Volume 20, Number 24

From [e-mail]  Wed Jun  6 15:44:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05120; Wed, 6 Jun 90 15:44:02 -0400
Posted-Date: 5 Jun 90 21:38:23 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA06278; Wed, 6 Jun 90 14:43:54 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00600; Wed, 6 Jun 90 14:53:59 cdt
From: Russell J. Abbott <aerospace.aero.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Overview/tutorial material on POSIX and GOSIP
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Russell J. Abbott)
Organization: The Aerospace Corporation, El Segundo, CA
Date: 5 Jun 90 21:38:23 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Russell J. Abbott)

We are suddenly in need of tutorial material on POSIX and GOSIP.  The
material should ideally discuss such things as the kinds of services
offered, advantages and disadvantages of adoption, timelines of expected
use and how widespread their adoption is likely to be, etc.  If anyone
can point to relevant articles, your help would be greatly appreciated.
Thanks.

-- Russ Abbott

Volume-Number: Volume 20, Number 25

From [e-mail]  Wed Jun  6 15:44:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05201; Wed, 6 Jun 90 15:44:25 -0400
Posted-Date: 4 Jun 90 17:04:29 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA06325; Wed, 6 Jun 90 14:44:21 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00670; Wed, 6 Jun 90 14:59:56 cdt
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ANSI vs POSIX on <sys/types.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 4 Jun 90 17:04:29 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From:  Andy Tanenbaum <[e-mail]>
>If one replaced the *_t types by their definitions everywhere, then a
>decision to change pid_t from, say, int, to, say, long, would require
>a real expert to dig through all the code to find those int's that really
>are pid_t's.

You miss an important point -- we're talking about system code provided
by the IMPLEMENTOR, not application code.  Presumably the implementor
IS a real expert, and furthermore is in charge of the decision about
what specific typedefs will be used.  I suspect that many implementors
will provide (for implementation use only) additional headers, say
<sys/_types.h>, that define identifiers such as __pid_t that are just
like the POSIX ones but taken from the name space reserved for use by
implementations.  Then, for example, <sys/types.h> could contain:
    /* <sys/types.h>: */
    #include <sys/_types.h>
    #define pid_t __pid_t
and <signal.h> could contain:
    /* <signal.h>: */
    #include <sys/_types.h>
    #ifdef _POSIX_SOURCE
    extern int kill(__pid_t, int);
    #endif
which addresses the maintenance issue that the implementor might be
faced with.  (Applications are oblivious to all this substructure,
which is the way things SHOULD be.)

>This then raises the question of how to make pid_t known.  In the example
>implementation given, <sys/types.h> is included in raise.c.  If this is
>indeed legal, then that is clearly one way to do it, as presumably all the
>names introduced by <sys/types.h> are not present in the object file,
>raise.o, and thus do not pollute the name space.

Yes, that was one of the points of the example.

>However, why do you urge not to put #include <sys/types.h> into <signal.h>
>under protection of #ifdef _POSIX_SOURCE?

Because I don't think that use of _POSIX_SOURCE should pollute the
name space beyond the minimum required for POSIX.

Volume-Number: Volume 20, Number 26

From [e-mail]  Fri Jun  8 01:45:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28272; Fri, 8 Jun 90 01:45:54 -0400
Posted-Date: 7 Jun 90 15:21:45 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA25089; Fri, 8 Jun 90 00:45:50 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02995; Thu, 7 Jun 90 23:39:36 cdt
From: Karl Heuer <IMA.IMA.ISC.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ANSI vs POSIX on <sys/types.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 7 Jun 90 15:21:45 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Karl Heuer)

In article <[e-mail]> From:  Doug Gwyn <[e-mail]>
>In article <[e-mail]> From:  Andy Tanenbaum <[e-mail]>
>>However, why do you urge not to put #include <sys/types.h> into <signal.h>
>>under protection of #ifdef _POSIX_SOURCE?
>
>Because I don't think that use of _POSIX_SOURCE should pollute the
>name space beyond the minimum required for POSIX.

In an earlier thread in this newsgroup, it was decided that this is in fact a
requirement of POSIX.  (Clarified in the Supplement, I believe.)  If the user
himself has not included <sys/types.h>, then the name `pid_t' is not reserved
to the implementation, and so it falls in the user's namespace.

Karl W. Z. Heuer ([e-mail] or harvard!ima!karl), The Walking Lint

Volume-Number: Volume 20, Number 27

From [e-mail]  Fri Jun 15 02:54:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03271; Fri, 15 Jun 90 02:54:22 -0400
Posted-Date: 12 Jun 90 20:48:41 GMT
Received: by cs.utexas.edu (5.61/1.63)
    id AA12582; Fri, 15 Jun 90 01:15:10 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06131; Thu, 14 Jun 90 23:17:29 cdt
From: Bob Lenk <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ANSI vs POSIX on <sys/types.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 12 Jun 90 20:48:41 GMT
Apparently-To: [e-mail]

From:  Bob Lenk <[e-mail]>

In article <[e-mail]> [e-mail] (Karl Heuer) writes:

> In an earlier thread in this newsgroup, it was decided that this is in fact a
> requirement of POSIX.  (Clarified in the Supplement, I believe.)  If the user
> himself has not included <sys/types.h>, then the name `pid_t' is not reserved
> to the implementation, and so it falls in the user's namespace.

It is worth pointing out that official interpretations of an IEEE
standard can only be issued by the IEEE.  Discussions in this newsgroup
(including this posting) can be very informative and useful, but they do
not decide the meaning of the standard.  In fact, there has been an
official request for an interpretation in this area, and I understand
the interpretation being issued is that all namespace reserved for the
implementation by the 1003.1-1988 standard is reserved whenever any
header mentioned in the standard is #included with _POSIX_SOURCE
#defined.

Draft 5 of the 1003.1a revision (actually 1003.1-199x) makes some changes
in this area, but clearly reserves names ending in _t when any POSIX.1
header is included.

        Bob Lenk
        [e-mail]
        hplabs!hpfcla!rml

Volume-Number: Volume 20, Number 28

From [e-mail]  Fri Jun 15 03:01:00 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05237; Fri, 15 Jun 90 03:01:00 -0400
Posted-Date: 11 Jun 90 11:42:35 GMT
Received: by cs.utexas.edu (5.61/1.63)
    id AA12602; Fri, 15 Jun 90 01:15:21 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06239; Thu, 14 Jun 90 23:24:34 cdt
From: Chuck.Phillips <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
Date: 11 Jun 90 11:42:35 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Chuck.Phillips)


>>>>> On 23 May 90 16:31:58 GMT, [e-mail] (Mike Schultz) said:
Mike> For REAL TIME purposes, shared memory functionality  is very useful, but
Mike> REQUIRING it to map files would be unacceptable for many implementations.

It *seems* to me that directly implementing mmap() with SVr4 semantics
under VMS, AGEIS (and of course Multics :-) would be possible.  UNIX
appears to be the late comer with shared memory.  Am I missing something?

Mike> ...

Mike> Now here are the latest developments.  SVR4 has taken the step of
Mike> implementing mmap without requiring it to be a file.  It states that one
Mike> is mapping in a virtual memory object instead.  It may be possible for
Mike> the SVR4 wording of mmap to be used as existing practice.  There will
Mike> have to be some functionality labeled as implementation defined.

Regarding IPC and mmap():

If I understand the SVr4 implementation of mmap() correctly, it is only
possible to share write enabled memory between processes if mmap()ing a
file system file, but not possible using "anonymous" (a.k.a. swap) memory.
Is it possible, and if it is possible, are you restricted to sharing
anonymous memory between parent and child processes due to lack of a
file system handle?

In any case, is (or are there plans for) one of the POSIX groups to address
mmap() (or whatever it will be called) specificly as a method of IPC?  It
appears SVr4 shared memory (shmat(), et al) offers little mmap() does not
(or couldn't easily be added, like handles).

Sorry if this posting is redundant.  We only recently started recieving a
full comp.* feed.

    Thanks in advance,
--
Chuck Phillips  MS440
NCR Microelectronics             Chuck.Phillips%FtCollins.NCR.com
Ft. Collins, CO.  80525           uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 20, Number 29

From [e-mail]  Wed Jun 20 01:58:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10618; Wed, 20 Jun 90 01:58:46 -0400
Posted-Date: 18 Jun 90 20:01:40 GMT
Received: by cs.utexas.edu (5.61/1.63)
    id AA13382; Wed, 20 Jun 90 00:58:43 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13243; Tue, 19 Jun 90 20:24:42 cdt
From: Gordon Spoelhof <[e-mail]>
Newsgroups: comp.std.unix
Subject: The FEDERAL MODEL
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: kodak.com![e-mail]
Organization: Eastman Kodak Co.
Date: 18 Jun 90 20:01:40 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Gordon Spoelhof)

A few years ago, Al Hankerson of NIST gave a talk on Open Systems.  In it
he refenced the "FEDERAL MODEL" which seemed to be roughly equivalent to the
X/OPEN model.  Can anyone direct me to where I can find out more about the
Federal model - how it relates to other efforts (GOSSIP, POSIX, etc); how
it affects FIPS; and how it relates to X/OPEN...

Thanks in advance,

Gordon Spoelhof
Computer Technology Consultant
Eastman Kodak Co. - Information Technology Management

Disclaimer:        "Neither my wife nor my employer endorse opinion according
                   to Gordi..."

Internet:          [e-mail]
Telephone:         [phone]
Secretary:         716-724-1365 (Sharon Hancock)
FAX:               716-781-5799
US Mail:           Gordon Spoelhof
                   CIS/ITM 2-9-KO
                   Eastman Kodak Co
                   343 State Street
                   Rochester, NY 14650-0724

Volume-Number: Volume 20, Number 30

From [e-mail]  Wed Jun 20 01:59:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10886; Wed, 20 Jun 90 01:59:50 -0400
Posted-Date: 17 Jun 90 10:49:17 GMT
Received: by cs.utexas.edu (5.61/1.63)
    id AA13627; Wed, 20 Jun 90 00:59:44 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13834; Tue, 19 Jun 90 22:16:25 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.unix.questions,comp.lang.perl,comp.std.unix
Subject: Re: Regular Expression tool
Keywords: POSIX, 1003.2, regular expression
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tsa.co.uk![e-mail]
Followup-To: comp.unix.questions
Organization: The Standard Answer Ltd.
Date: 17 Jun 90 10:49:17 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

Note Followup-To: above.  Post elsewhere iff you think appropriate.

In article <[e-mail]> [e-mail] (Bill Mulert) writes:
: ... I would
: like to have a tool, call it regex, that would allow me to say:
:
: regex ' "^[^=]*=\(.*\)\" '
: and have regex say, in plain language, what the expression means.

In article <[e-mail]> [e-mail]
(Larry Wall) writes:
>It's not likely to be too practical, for a couple of reasons.
>
>First, there a number of different standards out there.  For instance,
>sed and expr use \( ... \) to indicate grouping, while egrep and perl
>use ( ... ) for grouping, and \( and \) to indicate real parens...

We interrupt this posting for a word from our Sponsor Executive
Committee.  But seriously, the 1003.2 working group for the Shell and
Tools has at least documented the sh*t out of both ``Basic Regular
Expressions'' (as in ed) and Extended Regular Expressions (egrep) (and
perl, not that the thought of getting their claws (clauses?) into perl
seems yet to have occired to standards people).  The result of 1003.2
should be no obvious functional change in your favourite RE-using
utility, but rather the clearing up of what should happen in any number
of limiting cases around their edges.  (Actually, there are wide
ranging and useful functional extensions, which add yet more
hieroglyphic syntax: [=, =], [: and :] become special.  These
character pairs were chosen so as to minimise the danger of breaking
existing REs.)  The availability of a rigorous definition of REs and
EREs should make easier the work of anybody who wants to write a RE to
English translator.  (1003.2 could be considerably mor rigorous if it
used formal techniques, but let's leave that for another year or few.)

>  On top of that, when are ?, +, |, { and } metacharacters?  They
>are in some programs, and aren't in others.  Are you going to have a
>switch?
>
>    regex -sed   ' "^[^=]*=\(.*\)\" ' # In 1003.2
>    regex -expr  ' "^[^=]*=\(.*\)\" ' # In 1003.2
>    regex -egrep ' "^[^=]*=\(.*\)\" ' # In 1003.2
>    regex -ed    ' "^[^=]*=\(.*\)\" ' # In 1003.2
>    regex -perl  ' "^[^=]*=\(.*\)\" ' # Not 1003.2 territory
>    regex -emacs ' "^[^=]*=\(.*\)\" ' # Not 1003.2 territory
>    regex -vi    ' "^[^=]*=\(.*\)\" ' # In 1003.2 User Portability
                      #   Extension

Probably, even with 1003.2: the precise details of RE syntax vary between
utilities, as those who worked on the standard usually opted in favour of
documenting existing practice, even when the temptation to fix things was
strong.  Of course, to conform to 1003.2's command line syntax rules, usage
would have to be

    regex -t sed; regex -t expr      # or similar...
>
>Second, your big problem is not so much the regular expressions themselves
>as it is all the quoting you have to put around them because of the paucity of
>quoting mechanisms.  Take your first example:
>
>    echo "`expr \"$1\" : \"^[^=]*=\(.*\)\"`"
>
And so on, at rightly frustrated length.

One of several features which the 1003.2 definition of the shell lifts from
the korn shell is the construct

    $(command)

as a preferred alternative to the now-deprecated

    `command`

(It's stuff like this which has vendors jumping up and down, complaining
that they'll actually have to do some work before they can conform to the
standard.)  The new construct does cut down on the number and depth of
backslashes needed in... er... more interesting shell commands.  Although
my fingers still fly for the backslashes, even though I normally use a
korn shell...

>Unix is not a simple language.

I guess it's that way because it was designed to be easy for simple
computers to understand.
--
Dominic Dunlop


Volume-Number: Volume 20, Number 31

From [e-mail]  Thu Jun 21 18:02:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26630; Thu, 21 Jun 90 18:02:12 -0400
Posted-Date: 21 Jun 90 19:47:14 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11445; Thu, 21 Jun 90 17:02:06 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18884; Thu, 21 Jun 90 16:36:44 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.12: PII
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 19:47:14 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.12: PII

Andy Nicholson <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Introduction

For starters, we've had some significant turnover.  [Editor:
Including, you'll note, Steve Head, our former, fine dot 12 snitch.
Thanks for diving in, Andy.] We are now down to five participants who
were present a year ago, are on our third AT&T representative, and an
HP representative has permanently left the working group.  Despite all
this, the group is beginning to make rapid advances on both the
Simplified (SNI) and Detailed (DNI) network interfaces.  This
meeting's progress is sketched below.

Overview of the Work We're Doing

The dot 12 committee is working on three projects: Simplified Network
interface (SNI), Detailed Network Interface (DNI), and Data
Representation Interface (DRI).  Work on DRI is being delayed until
SNI and DNI are well along.  DNI is a protocol-independent interface
to network services that allows access to protocol-dependent features
in a protocol-independent manner.  DNI is meant to provide a complete
interface to everything you might expect to be able to do with
networking services.  DNI is comparable to Berkeley Sockets or AT&T's
TLI, and we plan that anything that can be accomplished with those
interfaces will be subsumed by DNI.

The idea behind SNI is that many applications will not require
``detailed'' access to networking services.  SNI gives a ``stdio''
type of interface for networking that combines common groupings of
procedures, eliminates access protocol-dependent features, and is just
plain easier to use.  Applications that use SNI aren't necessarily
simple, they just don't need DNI's detailed access to networking
services.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 Standards Update                            IEEE 1003.12: PII

                - 2 -

Simple Network Interface

We started the week discussing the SNI interface.  Norm Smith, from
Unisys, had intended to bring an alternate SNI proposal to this
meeting, but his group at Unisys decided to work with the current one.
Irene Hu, from DEC, says she may yet offer an alternate proposal.

I presented a paper, prepared from previous minutes, which gathered up
some deferred issues relating to SNI and we resolved some of them.
For example, we added some explicit goals for SNI that everyone seemed
to have accepted implicitly, but were never made official.

We also considered creating a formal definition of SNI functionality,
to help us determine whether any particular function should be
included, but decided it would be more efficient to keep deliberating
each case individually.  We'll record the rationale for each as part
of the standard document to help us avoid and respond to ballot
objections.

   + SNI functionality
     A paper by Tim Kirby (who works with me at Cray Research)
     prompted the group to redefine a function call.  Sni_recv(), was
     defined to discard excess data in a datagram when the buffer
     offered by an application isn't large enough.  The new version of
     Sni_recv(), allows an application either to discard excess data
     or to perform multiple sni_recv() calls to read it all.  It also
     allows applications to discard datagrams without reading them at
     all.  Here, I think the group has noticeably extended the power
     of the interface without sacrificing efficiency.

   + Kernel objects
     Because SNI endpoints may not be kernel objects, we need to
     define semantics and interfaces that will allow SNI endpoints to
     survive exec().  Unfortunately, we disagree on the semantics of
     the endpoint-preservation procedures.  Should multiple copies of
     the same endpoint exist in different processes' address spaces,
     as happens with fork() and exec()?  Implementing the protocol
     stack in a user library creates multiple copies of state
     information for the same endpoint, and it may be impossible to
     keep them synchronized.

     Some of us (Keith Sklower, from Berkeley, the author of the SNI
     document, and I) want to restrict endpoint semantics so that only
     one process may have a copy of an SNI endpoint; others (Irene and
     Norm) disagree and wish to allow multiple copies of SNI endpoints
     where the programmer wishes.

May 1990 Standards Update                            IEEE 1003.12: PII

                - 3 -

Detailed Network Interface

We discussed DNI procedures in detail for the first time and found
tentative agreement on most of the many issues raised.  Mike Karels,
from Berkeley's Computer Science Research Group, presented an outline
of required functionality.  After discussing it, we agreed to make DNI
endpoints POSIX file descriptors (as returned by open()) until we see
a compelling counter-argument.  I'll challenge you to offer one.

On Wednesday, Irene gave an overview of XTI.  During the presentation,
Torez Hiley, our new attendee from ATT, told us that XTI is being
revised: input from vendors using the Berkeley socket interface is
prompting the addition of many features.  Torez will report on the
upcoming revision at the July meeting.  Where sockets and XTI/TLI
differ, the best solution is not clear.  Moreover, some features are
absent or inadequately supported in both interfaces.  Here, we have a
lot of work to do and are just getting started.  We're eager to hear
whether the new XTI solves any of our problems.

May 1990 Standards Update                            IEEE 1003.12: PII


Volume-Number: Volume 20, Number 32

From [e-mail]  Thu Jun 21 18:02:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26744; Thu, 21 Jun 90 18:02:29 -0400
Posted-Date: 21 Jun 90 19:57:52 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11487; Thu, 21 Jun 90 17:02:19 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18902; Thu, 21 Jun 90 16:37:43 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 19:57:52 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>
From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions

John Gertwagen <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

1.  Administrivia

P1003 met in Salt Lake City this time.  Actually, it was at Snowbird
Lodge, south of and well above the city.  It was spring in Salt Lake
but still winter in the mountains.  (Wish I skied.) The real-time
meetings drew 68 people the first day, and averaged around 40 all
week.  If some skiers hadn't deserted each day, we would have had
more.

2.  .4 Balloting

Over 200 people joined the balloting group for P1003.4, Draft 9.  The
first ballot closed in mid-March and 75% of balloters returned their
ballots within a day or two of the official deadline, setting a new
record!  43% of these voted ``Yes'' on the first round, about average
for POSIX ballots.

Lack of time and logistics problems meant little ballot feedback by
meeting-time, (shame on those who didn't submit their ballots
electronically!) but a few issues surfaced.  Several objected to
having binary semaphores only in the path namespace and not also in
shared memory, where they could use simple test-and-set calls, and not
time-consuming system calls.  There's value providing a common
interface for both of these and for other ``synchronization objects.''

There were also objections to having ``events'' when there are
``fixed'' signals in System V, Release 4.  The technical reviewer for
events will try to make SVR4 signals meet real-time requirements.
(Not too long ago, there were strong objections to changing signals.
There may still be protests over adding real-time-required
determinism.)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 2 -

3.  Current Work

With .4 in limbo, the working group got on with Threads (.4a),
Language Independent Bindings (.4b), and Real-time Application
Environment Profiles (.14).  Threads got the most attention.
(Surprised?) Despite this, or perhaps because of it, the other two
drafts saw significant progress.

Rick Greer has reviewed a lot of the threads work, so I'll briefly
mention what's going on in .4b and .14, give you some personal views
on threads, and then amplify on areas where our editor, Jeff Haemer,
was recently raked over the coals.

4.  AEP

At first, the real-time AEP small group had some trouble focusing.
They've identified two fairly easy targets, essentially minimum and
maximum configurations, and now seek proposals for intermediate
specifications.

In Utah, the group came up with a fairly complete specification for
embedded systems, and reviewed it with P1003.0 --  the POSIX Guide
group that is the driving force in defining AEP's.  One interesting
issue surfaced during the review: for embedded systems, the AEP group
wants to exclude interfaces of .4 and .1 that aren't needed!  Dot zero
hadn't thought of that before.  Resolving this should set an
interesting precedent.

5.  Language-Independent Bindings

The people doing this have it down to a science, so the large group
has largely left them alone.  Most of their work is converting things
to ``normal'' form, which is mostly tabular, and throwing away the
stuff that is language-dependent.  They made good use of their time,
cranking through a good bit of the .4 draft.

6.  Threads (P1003.4a)

The meeting saw two new proposals.  Both suggested fruitful changes to
the current Pthreads work, but neither was accepted as a new base for
the current draft.

John Zolnowsky of Sun Microsystems submitted one counter-proposal,
called ``strands'' because ``threads'' was already taken.  It was an
attempt to limit the scope of the interfaces and keep thread semantics
closer to process semantics.  Thus, it would have done away with
mutexes and conditions, leaving synchronization to be accomplished
through .4 binary semaphores, presumably modified to have inter-

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 3 -

thread, not just inter-process semantics.  It also proposed more
process-like exit semantics and a version of per-thread signaling.
The consensus on the strands proposal seems to have been that it was
too minimal.

In contrast, the VP (Virtual Processor) proposal, by Paul Borman of
Cray Research, proposed significant ``incremental'' functionality in
the form of a lower-level, virtual-processor interface for use by the
multi-processing and parallel processing communities.  (For those
familiar with Mach, it is roughly to Pthreads as cthreads is to
Cthreads.) Features of the VP proposal included:

   + fork() and exec() semantics for VPs

   + per-VP signal semantics

   + locks and events for synchronization

   + no ordering or scheduling constraints

The group had several concerns about VP

   + Could it support real-time requirements without ordering and
     scheduling constraints?

   + Could the Pthreads constraints be implemented on top of a layer
     that didn't support them?

   + Would the interfaces be used by applications or by system
     implementors?

   + Would an application using both Pthreads and VP interfaces
     encounter analogous problems to those caused by read()s and an
     fread()s on the same file?

   + Would standard interfaces for locks and events, implemented in
     hardware on many systems, constrain or encourage hardware
     development?

   + Would the standard benefit either the user or vendor community?

   + How soon could the proposal be completed and gain enough of the
     MP community's consensus to go to ballot?

Perhaps the deciding factor, though, was that the multi-processing AEP
group (P1003.16) started meeting officially at Snowbird.  [Editor:
Watch for the snitch report, coming soon.] A majority of our group
(including me) felt that MP-specific standards should grow from
requirements identified by .16, not be created on the fly by the
real-time working group.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 4 -

In areas that are still not pinned down, the group made progress
towards a better-defined cancellation mechanism, towards a ``signals
compromise'' that improves on one hurriedly forged at the previous
meeting, and towards more process-like exit semantics.  The consensus
was that we should try to accommodate and specify per-thread signal
state.  Although there are a few strong supporters, a majority did not
feel that specification of per-thread signals is essential to a
standard.

Paul Borman of Cray Research will present a proposal on this at the
next meeting.  I'll be interested to see what Paul comes up with.
With three state elements, (mask, pending signals, and action vector)
and at least three signal delivery types (one, some, all), I can
create many implementation models and corresponding application
architectures.  It may prove easy to construct a plausible model, but
hard to construct one that 40 engineers can agree to live with for a
long time!  I suspect a portable application can assume nothing more
than ``exactly one signal gets delivered exactly once to exactly one
handler.'' (Looks an awful lot likes signals to a process, doesn't
it?)

The biggest progress in the meetings was wide consensus achieved for
the current threads proposal.  The working group resolved many of the
remaining threads issues, and we let Bill Corwin tell IEEE/ISO that we
expect to ballot P1003.4a in July, after the next meeting.

7.  OSF and UI Cooperating?

Our editor's recent editorial stirred up a hornet's nest.  (It wasn't
so much what Jeff said as what he implied.) In his follow-up posting,
he said I'd speak about the joint meetings in more detail.  I didn't
really want to but he twisted my arm, so here goes.

The UI MP Working Group and OSF have been cooperating since the middle
of last year.  I happen to work for a company that belongs to both,
INTERACTIVE Systems Corporation, and though I haven't been to all of
the joint meetings, I've attended them off and on since last November
(which is I think, when they started).  Those I have attended focused
on finding solutions to interface/semantic problems that both OSF and
UI can endorse and that P1003.4 would probably endorse as well.
Although these meetings haven't been advertised I've seen at least one
article about OSF/UI/ATT negotiations that mentioned their cooperation
in the MP arena.  And the meetings have been open.  At least one non-
member has shown up uninvited, and was not asked to leave.

Now, it's no secret that several Pthreads-proposal initiators
(instigators?) work for OSF sponsors.  Since the Pthreads-proposal was
advanced before OSF adopted Mach, it's hard to say whether OSF
influenced the P1003.4 work or the other way around.  Also, in several
instances, OSF/UI members have voted personal opinions contrary to the
OSF/UI consensus established at the joint meetings.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 5 -

What's the point?  The joint meetings contribute to the quality of the
..4a work, but they don't drive it.  I think the work in P1003.4 is
pushing vendors to find multi-threading solutions faster than they
would have on their own.  It's an example of POSIX pushing emerging
technologies, not just creating standards.  There's even a chance that
..4a will create a standard multi-threading interface before millions
of installed, heterogeneous systems force the standard to a lowest
common denominator or to incorporate a particular implementation's
garbage.

And POSIX is playing another role  --  uniting the industry.  I
believe Sun's tooth-and-nail fights with AT&T in P1003.1 led to their
current cooperation.  Maybe the collaboration of OSF and UI on threads
will also bring more unity to the industry.

8.  The relationship between .4 and .4a

Despite what some think, the threads small group has never had any
official status.  Interest and participation in the threads effort
goes far beyond the small group, or even the .4 working group into
other POSIX committees.  Some history may clear this up.

Lightweight processes (i.e., threads) have been on P1003.4's list of
potential work items since its formation.  About 3 years ago, the
working group voted not to pursue them because they were not clearly
needed and the technology was not sufficiently mature.

About a year and a half ago, threads resurfaced as an item of interest
to the real-time users, and also to Ada, Transaction Processing, and
RPC working groups.  A small band of ``experts'' went off to draft a
proposal.  Since P1003.4 was an active system-interfaces committee and
the real-time user community wanted a threads proposal, a lot of hard
work culminated last summer in Minneapolis in a threads proposal being
accepted as an additional chapter for the .4 draft.

There are 12 other interface proposals in the .4 draft.  Some have
been mature for nearly two years, (some with broad consensus, others
without), others are still relatively wet behind the ears.  Still, all
the interfaces are relatively complete (sometimes too complete?), and
in November, when it seemed appropriate to send .4 to ballot, At the
Milpitas meeting, the P1003.4 working group decided to include the
threads chapter in the ballot for comment only, and sought and
obtained authorization to turn the threads work into a separate work
item for the P1003.4 working group.

After the Pthreads proposal was accepted into .4, the small group of
people whose primary interest was threads spent all their time on
threads.  Meanwhile many other .4 members time-shared all the other .4

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 6 -

activities.  Because the Pthreads supporters were so focused, they
sometimes seemed like a separate group.  (Some in the small group
might have been surprised to learn they weren't.  It takes a while to
understand the POSIX bureaucracy.) Nevertheless, though they may not
always have appeared to represent the entire working group, the
Pthreads proposal now enjoys wide consensus.  Apparently, the small
group has listened well to the interests of the working group and the
POSIX community.

At Snowbird, there wasn't a threads small group, there were seven of
them!  These small groups examined how the current and the alternative
proposals addressed:

   + thread management

   + synchronization

   + signals/asynch events

   + cancellation

   + thread-specific data

   + re-entrant functions

   + process control

After reviewing all the issues, we discovered a consensus in most of
these areas, and fairly strong agreement on most issues in the three
or four groups that are still needed.  It looks like things are pretty
well on target.

I'm partially responsible for pushing .4a in before .4 was done, so
I'm partially responsible for the process's not always appearing fair
or well organized.  I'll take my share of the blame.  But I'll also
take my share of the credit for progress in a technology that I
believe to be important for real-time and for the entire POSIX
community.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 20, Number 33

From [e-mail]  Thu Jun 21 18:02:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26860; Thu, 21 Jun 90 18:02:47 -0400
Posted-Date: 21 Jun 90 20:06:46 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11531; Thu, 21 Jun 90 17:02:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18922; Thu, 21 Jun 90 16:38:51 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 20:06:46 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods

Doris Lebovits <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Dot three's job is to do test methods for all of the other 1003
standards.  The group's work, whose first parts are now in ballot,
specifies the requirements for OS conformance testing for our industry
and for NIST.  This makes what the balloting group and technical
reviewers are doing, and their schedules, worth watching.  Pay
attention, also, to what comes out of the Steering Committee on
Conformance Testing (SCCT).  Their projects and decisions will be
interesting and important.

This was the working group's sixteenth meeting.  As usual, we reviewed
the ballot status of P1003.1 test methods, worked on P1003.2 test
methods, and reviewed steering committee activities.  As before, each
morning we did technical reviews of parts I and II; afternoons were
spent writing assertions for part III.  Participants from the usual
companies attended.  (AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data
General, Cray Research, Unisys, Perennial, and Unisoft Ltd.)

Document structure and some new PARs

Currently, our evolving document has two parts: Part I is generic test
methods; Part II is test methods for measuring P1003.1 conformance,
including test assertions; and Part III contains test methods and
assertions for measuring P1003.2 conformance.  (As other P1003
standards evolve, they will become separate activities in the working
group's schedule.)

After the ballot, each part will become a separate standard.  Part I
will be published as IEEE P1003.3; Part II as IEEE P1003.3.1; and Part
III as IEEE P1003.3.2.  To this end, we developed and submitted three
new PARs to the Standards Executive Committee (SEC).  The PAR for
P1003.3 lets Part I apply to all TCOS standards (i.e., POSIX).  The
PAR for P1003.3.1 lets Part II include test methods for P1003.1 and
P1003.1a.  The PAR for P1003.3.2 lets Part III include test methods
for P1003.2.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June, 1990 Standards Update                  IEEE 1003.3: Test Methods


                - 2 -

Ballot status

Draft 11 of the current ballot, which was re-circulated to the
(approximately) ninety-member balloting group late in February, closed
balloting March 23.  Of the 65 respondents, 29 approved, 17
disapproved, and 19 abstained.  This meets the two-thirds response
requirement, but falls short of the needed two-thirds approval.
Another re-circulation will probably take place in Fall, 1990.

P1003.2 verification

This was our fourth meeting working on a verification standard for the
P1003.2 standard.  The assertion writing and review were done in small
groups.  Some of the assertions were based upon P1003.2 Draft 9.  This
group needs help from the P1003.2 working group in writing test
assertions, but no formal arrangement is in place yet to provide it.

Officers for the P1003.2 Test Methods activities are: Ray Wilkes
(Unisys), Chair; Lowell Johnson (Unisys) Secretary; and Andrew Twigger
(Unisoft Ltd), Technical Editor.

Steering Committee on Conformance Testing (SCCT)

The test-methods steering committee is supposed to alleviate the
increasing dot-three work load all the other, proliferating groups are
creating.  Their job is coordinating the activities of all test-
methods groups, monitoring their conformance to test methods, and
writing Project Authorization Requests (PARs).  Currently, its members
are Roger Martin (NIST, Steering Committee Chair), Anita Mundkur (HP),
Andrew Twigger (Unisoft Ltd), Bruce Weiner (Mindcraft), and Lowell
Johnson (Unisys), but membership will be dynamic, Right now, this
committee is documenting procedures.  Roger Martin is also clarifying
which standards the working group will address.  The Technical
Reviewers will review this work sometime before the next meeting.

June, 1990 Standards Update                  IEEE 1003.3: Test Methods


Volume-Number: Volume 20, Number 34

From [e-mail]  Thu Jun 21 18:03:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26982; Thu, 21 Jun 90 18:03:02 -0400
Posted-Date: 21 Jun 90 20:17:50 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11544; Thu, 21 Jun 90 17:02:52 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18940; Thu, 21 Jun 90 16:39:41 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 20:17:50 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools

Randall Howard <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

Background on POSIX.2

The POSIX.2 standard deals with the shell programming language and
utilities.  Currently, it is divided into two pieces:

   + POSIX.2, the base standard, deals with the basic shell
     programming language and a set of utilities required for
     application portability.  Application portability essentially
     means portability of shell scripts and thus excludes most
     features that might be considered interactive.  In an analogy to
     the ANSI C standard, the POSIX.2 shell command language is the
     counterpart to the C programming language, while the utilities
     play, roughly, the role of the C library.  POSIX.2 also
     standardizes command-line and function interfaces related to
     certain POSIX.2 utilities (e.g., popen, regular expressions,
     etc.) This document is also known as ``Dot 2 Classic.''

   + POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base POSIX.2 standard; it will eventually be an optional
     chapter of a future draft of the base document.  The UPE
     standardizes commands, such as screen editors, 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 that attempts to reduce retraining costs incurred by
     system-to-system variation.

     Some utilities, have interactive as well as non-interactive
     features.  In such cases, the UPE defines extensions from the
     base POSIX.2 utility.  An example is the shell, for which the UPE
     defines job control, history, and aliases.  Features used both
     interactively and in scripts tend to be defined in the base
     standard.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June 1990 Standards Update                IEEE 1003.2: Shell and tools


                - 2 -

Together Dot 2 Classic and the UPE will make up the International
Standards Organization's IS 9945/2 - the second volume of the proposed
ISO four-volume standard related to POSIX.

In addition to providing current information about the activities of
the Working and Balloting Groups for POSIX.2, a special topic of focus
will be chosen for each report.  Therefore, the reader is referred to
earlier reports for information on such topics as the history of the
Shell Wars and the controversial scope of the UPE.  The next section
talks about the functions, rather than utilities, that are found with
POSIX.2.

The POSIX.2 API Functions

Perhaps it will come as a surprise to many readers that the POSIX
Shell and Utilities standard also contains specifications for about
fourteen new or extended C function bindings -- in effect, its own API
extending the POSIX.1 bindings -- as follows:

  confstr(), sysconf() The first function was created to provide
            string-valued, configuration-specific values such as the
            default setting of the PATH environment variable.  The
            second extends the POSIX.1 function of the same name with
            numeric-valued configuration information such as the
            largest scale value in the bc utility and the
            implementation's line length restriction.

  fnmatch() This functional interface implements the form of pattern
            matching used by file-name generation (glob) in the shell,
            case statements in the shell, and the -name option of the
            find utility.

  getopt()  This functional interface provides a standard utility
            argument parser that enforces the ``standard utility
            syntax'' guidelines and might be used to implement the
            getopts utility from POSIX.2.

  glob(), globfree() This set of functions does shell-style file-name
            generation and presumably calls the fnmatch() function.

  popen(), pclose() This pair of functions, which is a part of the
            standard I/O package on conventional UNIX systems,
            provides the ability to communicate through pipes to
            another process by executing a string in the POSIX.2 shell
            language.

  regexec(), regcomp() This set of routines provides support for both
            the Basic and Extended Regular Expressions defined in
            POSIX.2, including full internationalization support.

June 1990 Standards Update                IEEE 1003.2: Shell and tools


                - 3 -

  wordexp(), wordfree() This set of routines provides a mechanism for
            an application to use word expansion (parameter expansion)
            that is compatible with the POSIX.2 shell language.
            Although most implementations of this routine will
            normally call the shell, it is (at least conceptually)
            possible that the shell be implemented to call these
            routines for word expansion.

  system()  This ``classical'' function executes a command written in
            shell language.

All of these functions form part of an optional C binding to POSIX.2
and it is expected that the soon-to-be-released, draft version of the
NIST FIPS will make this ``optional'' functional interface mandatory
for US government procurements.  Other language-binding working
groups, such as those exploring Ada and FORTRAN, are presumably
encouraged to add their own optional bindings if they so wish.

Although the inclusion of these functions seems to be a little out of
place in a shell-and-tools standard, there is some rationale for this.
In fact, when POSIX consisted only of POSIX.1, the early attempts to
define system() and popen() made apparent the need to completely
specify the shell language in which the argument string to these
functions was written.  That, in turn, along with the desire to
standardize the classical UNIX utility set, led to the creation of
POSIX.2 as the first offshoot group in the POSIX family of standards.
From this beginning, the POSIX.1 sysconf() function was extended and
the confstr() function was created to provide an underlying
implementation for the getconf utility, which allowed shell-level
applications to query configuration-specific values such as maximum
line length of text files.  Once the beachhead of having functional
interfaces in POSIX.2 was established, the temptation to continually
add to this list has led to the current list as of Draft 9.

On the other hand, there are some very strong arguments against the
inclusion of these functions.  First, although the regular expression
functions will almost certainly be required to implement many POSIX.2
utilities such as ed, grep, awk, sed, etc., these functions stop short
of the complete support needed to implement some utilities.  For
example, the handling of error messages (as in a syntactically
incorrect regular expression) and the mechanisms of doing
substitutions (including & and \n support) are not addressed.  Because
of this most implementors will be required to have ``non-portable,''
proprietary extensions to their regular expression support to make a
``commercially-viable'' implementation.  The issue of where to ``draw
the line'' between inclusion and exclusion is a difficult one indeed.
Second, vendors and application writers may find it difficult, both
procedurally and from a licensing perspective, to have part of the
subroutine library come from a POSIX.1 developer and the other part
implemented by the POSIX.2 implementor.  For example, the implementor
of sysconf(), popen(), or system() might do a much better job if

June 1990 Standards Update                IEEE 1003.2: Shell and tools


                - 4 -

common source code and assumptions were possible between the POSIX.1
and POSIX.2 APIs.

Status of POSIX.2 Balloting

``Dot 2 Classic'' remains in its second round of balloting on Draft 9
with a new draft going to ballot in the June-to-July time frame,
according to Hal Jespersen the POSIX.2 Technical Editor.

During the Snowbird meeting, much of Monday was devoted to a
presentation on the status of the Dot 2 Classic Balloting resolution.
It is possible, and indeed likely, that Hal Jespersen will limit
balloting on Draft 10 to unresolved objections and new material.  If
this is the case, it most likely indicates (although he didn't
specifically say) that Hal has confidence that Draft 10 has a high
probability of achieving the requisite 75% affirmative vote.
Personally, I am not convinced that this is a likely event.  While
some decisions will be reversed (perhaps several times) before Draft
10, the following is a summary of issues and/or changes appearing in
Draft 10:

   + The internationalization utilities locale and particularly
     localedef are still controversial, particularly within AT&T.
     Because of the strong rationale for their existence it appears
     that they will remain in Draft 10, certainly with considerable
     amendment as the UniForum Technical Committee on
     Internationalization refines these newly developed utilities.
     This is just one case where the conflict between the role of
     standards to codify existing practice and the obvious holes in
     existing practice creates controversy.  Perhaps this issue will
     be resolved by a balloting referendum such as was used for uucp.

   + The Draft 10 shell will almost certainly strongly resemble that
     of Draft 9.  Most of the important controversies appear to be
     largely settled and most changes appear to be corrections and
     clarifications.

   + Most complex utilities, such as awk, shell, lex, yacc, etc., have
     undergone extensive reworking in response to ballot objections.
     Often a seemingly simple objection will cause large parts of the
     description to be rewritten in order to tighten it up with
     respect to completeness and clarity.  I believe that Hal
     Jespersen believes that most of these changes are uncontroversial
     and he has ensured this by circulating draft sections via E-mail
     to various ``experts.'' Certainly, many of these utilities
     desperately needed this clarification.

   + It appears that the newly-engineered hexdump utility is to be
     replaced by a (much simpler) reversion to od.  While od is the
     existing practice, the POSIX od will be a superset of the
     original one with most useful functionality in the new parts.  It

June 1990 Standards Update                IEEE 1003.2: Shell and tools


                - 5 -

     is not clear that hiding new invention under the same name is any
     less controversial than advertising its existence.

   + Of course, there will be innumerable other changes, obviously
     important to many, that cannot for reasons of space be covered
     here.

A mock ballot on Draft 4 of the UPE was sent to the working group
during February 1990 to allow ballot resolution to be the main focus
of the Salt Lake meeting this April.

Status of the New Orleans Meeting

Monday, the working group reviewed the current status of the balloting
on ``Dot 2 Classic''.  This has already been discussed in earlier in
this report.

The other four days were spent reviewing the 600 to 700 objections
produced by the mock balloting process for the UPE.  While the number
of objections seems low compared to the rate of objections for the
corresponding number of pages in Dot 2 Classic, this may simply be a
symptom of a general shortage of time and the lower number of people
(generally 15 to 20) in the UPE working group.  This lower number and
general lack of time, is a reflection of the fragmentation of the
entire POSIX process caused by a proliferation of working groups.

Most of the work during mock balloting was of the nature of cleaning
up incomplete or poorly worded textual descriptions.  Particularly
controversial issues were often left in the rationale for Draft 5.
Some controversial utilities were moved to an appendix based upon the
belief that they should be removed while still allowing the balloting
group one last chance to save them.  The lint89 was one such utility
whose raison d'etre was meager.  At best, the functionality probably
should be an option to c89 in the ``Dot 2 Classic'' document.  The
sdiff utility which was inadvertently omitted from Draft 4, is to be
included in Draft 5.

Altogether, it appears that Draft 5 is in a relatively healthy state
to survive the rigors of the balloting process.  None the less, I
expect that there will be a greater number of objections in the
balloting this summer than there were in the mock ballot.

June 1990 Standards Update                IEEE 1003.2: Shell and tools


Volume-Number: Volume 20, Number 35

From [e-mail]  Fri Jun 22 01:58:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15962; Fri, 22 Jun 90 01:58:32 -0400
Posted-Date: 21 Jun 90 17:29:22 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA07782; Fri, 22 Jun 90 00:16:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19374; Thu, 21 Jun 90 23:33:35 cdt
From: Steve Emmerson <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: POSIX equivalent to <sys/file.h> or <fcntl.h>
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.unix.questions
Organization: University Corporation for Atmospheric Research (UCAR)
Date: 21 Jun 90 17:29:22 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Steve Emmerson)

Would some please tell me what header file (or files) is the POSIX-
equivalent to the BSD <sys/file.h> or the System V <fcntl.h>.

I have the P1003.1 document on order, but it will take 4 to 6 weeks to
arrive and I need to get on with my work.

Thanks in advance.

(If someone would send me a general header-file mapping, that would be
great!)

Steve Emmerson        [e-mail]        ...!ncar!unidata!steve

Volume-Number: Volume 20, Number 36

From [e-mail]  Fri Jun 22 13:51:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08050; Fri, 22 Jun 90 13:51:38 -0400
Posted-Date: 22 Jun 90 00:21:27 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA22292; Fri, 22 Jun 90 12:51:34 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20745; Fri, 22 Jun 90 12:39:46 cdt
From: <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 22 Jun 90 00:21:27 GMT
Apparently-To: [e-mail]

From:  [e-mail]

In article <[e-mail]> [e-mail] writes:
>   getopt()  This functional interface provides a standard utility
>             argument parser that enforces the ``standard utility
>             syntax'' guidelines and might be used to implement the
>             getopts utility from POSIX.2.

Might it not be time to "push the envelope" as 1003.4 has done, and specify
Eric Allman's far superior "parseargs" interface? Getopt really doesn't do
that much: a command line parser using getopt is only slightly simpler than
one assembled completely out of a nested loop, and it doesn't do anything
to help generate usage messages and the like... with the result that usage
messages that are out of date are not that uncommon, even in system programs.

Parseargs also helps by providing a system-independent interface, more so
if you use my extended version of the unix driver routine. That way folks
who work in other environments will be encouraged to produce programs that
follow the P1003.2 interface when compiled under POSIX... and POSIX programs
will fit well into VAX/VMS, MS-DOS, etc...
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 37

From [e-mail]  Fri Jun 22 20:43:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17291; Fri, 22 Jun 90 20:43:01 -0400
Posted-Date: 22 Jun 90 19:22:41 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA22512; Fri, 22 Jun 90 19:42:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22387; Fri, 22 Jun 90 16:48:19 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 22 Jun 90 19:22:41 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada bindings

Jayne Baker <[e-mail]> reports on the April 23-27 meeting
in Salt Lake City, UT:

Overview

The Utah meeting was the group's first since our October meeting in
Brussels.  In the interim, we had completed a mock ballot of Draft
4.0.  Jim Lonjers of Unisys, one of our two co-chairs, managed the
effort.  The document was mailed out to reviewers on December 1, 1989
and comments were due January 19, 1990.  Although only 16% of the
ballots were returned, the high quality of the comments received made
the mock ballot a success.  Ted Baker, of Florida State University,
hosted a special meeting in Tallahassee, March 19 - 23, to resolve
issues and comments; the result was draft 4.1.  We did not attend the
January, New Orleans meeting because balloters lacked sufficient time
to review and return comments prior to the meeting, though some
members came to attend other groups' meetings.

Our main goal in Utah was to prepare the Ada Language Binding Document
for IEEE and ISO Ballot.  We addressed the few, unresolved technical
issues from mock ballot; read draft 4.1 cover-to-cover, for accuracy
(of text and Ada code), content, and consistency; established a plan
for addressing the ISO formatting issues; adopted an optimistic
schedule for IEEE and ISO ballots; and tried to establish a position
on threads.

Unresolved Technical Issues from Mock Ballot

Most unresolved technical issues from the mock ballot were trivial,
and quickly resolved.  They included the details of iterations (e.g.,
through a directory), string lower bounds with respect to a string
returned by a function, the behavior of a file that is opened non-
blocking when the I/O operation cannot complete, static initialization
versus ``easy implementation'' of constants, and Text I/O page
terminators.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


                - 2 -

The most detailed discussion involved whether or not files should be
closed on an Exec.  The Ada binding provides a Start_Process function,
which is a primitive that safely creates a new process.  In the face
of Ada tasking, Fork and Exec are unsafe and cannot be used to
accomplish the results of a Start_Process call.  Once one of these
unsafe primitives is issued, an application program is no longer under
the control of the Ada run time system; the operating system is
involved.  Therefore, the integrity of the child process is
jeopardized, and the state of the process's I/O (i.e., which files are
open/closed) is not guaranteed.  Application programs that must be
safe with Ada tasking and must have files closed and buffers flushed,
should call Start_Process to create a new process.

Global Issues Effecting the Document

We solved several global, editorial issues.  We agreed to use a terse
wording style except where a more lengthy, explanatory style is needed
for clarity.  We accepted the current packaging of the Ada code
(multiple packages) and the non-Ada-Language-Reference-Manual coding
style.  Chapter authors were assigned action items to complete their
respective references and rationale sections.

We spent a large portion of the meeting going through the document,
chapter-by-chapter, noting very specific changes.  Changes recorded in
a ``master red-lined'' copy were forwarded to appropriate chapter
authors at the close of the meeting.  These changes will be made
before the June delivery of the document to WG 15.

ISO Format Issues

We need to make several minor modifications, additions, and deletions
before the June  WG 15 meeting, to put the document in ISO standard
format.  After the March, Tallahassee meeting, Jim Moore, of IBM,
investigated the possibility of hiring a consulting technical editor
to do this work.  IBM volunteered to fund this effort at a level
sufficient to translate the document into ISO format, maintain that
format, and make one major edit and two to three minor editorial
revisions.  We accepted IBM's offer, and hired Hal Jespersen.

Threads Issues

As in New Orleans, several group members met with P1003.4 for threads
discussions.  Most group members feel we should establish a position
on threads, but we remain firmly divided on what it should be.
Several members believe the currently defined primitives (i.e., the
most basic system functions) are insufficient, and think that any
thread model and primitives proposed should be sufficient to support
Ada tasking, and implement an Ada Run-Time.  In contrast, at least one
group member believes we are unrealistic to require a threads proposal
in C to meet Ada requirements --  we should, instead, require that C
and Ada be able to play together in some reasonable fashion, and have

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


                - 3 -

a fair understanding of how it will be accomplished.  We decided to
admit our dissension to P1003.4.  Interested P1003.5 members are
acting as liaisons to represent their own views, but these liaisons do
not represent any consolidated P1003.5. view.

The IEEE and ISO ballots

Steve Deller, our chair, asked the Sponsor's Executive Committee (SEC)
to approve our entry into the IEEE ballot process.  Jim Isaak, SEC
Chair, met with us early in the week to discuss the IEEE and ISO
ballot processes and help us establish a schedule to reach IEEE and
ISO ballots simultaneously.  Since the ballot process seems to be of
general interest, here is a brief overview.

A hierarchy of organizations is responsible for producing
international operating-system standards and managing the ISO ballot
process.  Two independent, international standards organizations, the
International Standards Organization (ISO) and the International
Electrotechnical Committee (IEC), sit on top.  Joint Technical
Committee 1 (JTC 1), a combined effort of these two organizations
designed to coordinate their efforts in areas of overlap, is at the
second level; Subcommittee 22 (SC 22), Languages, at the third; and
Working Group 15 (WG 15), Portable Operating Systems for Computer
Environments, at the fourth.  National organizations, such as the
American National Standards Institute (ANSI), manage ISO balloting
within each country.  Each participating country has one or more
representatives in WG 15.  The United States has a Technical Advisory
Group (TAG), which meets with and advises the United States' WG 15
representatives on the US's position on important issues.

This bureaucracy requires quite a bit of coordination and planning to
coordinate IEEE and ISO ballots.  Most documents require about one
year to complete the IEEE ballot cycle.  Historically, POSIX documents
have begun with the IEEE ballot process; three to four months later,
either the original draft, or a newer version incorporating IEEE
-ballot-process comments, enters the ISO process, and is delivered to
both WG 15 and SC 22 for approval.  Typically, the IEEE ballot is held
open until all comments from both IEEE and ISO processes are received,
reviewed, and incorporated.  The result is returned to both the IEEE
and ISO ballot groups for their approval.  If the IEEE comments are
substantive, they enter into the ISO process by the submission of a
United States position.  For example, P1003.1a is the U.S. position on
P1003.1..

Our group also initiated formation of a formal ballot group --  is the
group that will actually vote on the current draft.  We will deliver
Draft 5.0, in ISO format, to WG 15 at the Ada Europe meeting this
June.  Draft 6.0 will go to IEEE ballot on August 6.  If we receive
the required 75% response by September 21, the ballot will close
immediately; if not, we must reconsider the ballot group membership,
and revise our schedule. In early October, draft 6.0 will be delivered

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


                - 4 -

to SC22.  At the October meeting, in Seattle, we will resolve the IEEE
ballot comments and produce Draft 7.0, which will enter the ISO Ballot
process.  At the January '91, New Orleans Meeting, we will determine
whether a second IEEE Ballot is needed.  Any changes to Draft 7.0
resulting from a second IEEE Ballot will be entered into the ISO
process through a pro forma objection.  There are no guarantees, but
P1003.5 could reach Draft International Standard (DIS) status by late
second quarter of 1991.

Conclusion

The April '90/Salt Lake City Meeting was a success.  We addressed the
issues we hoped to address and attained our goal for the meeting.  We
also established a schedule for reaching IEEE and ISO ballot; although
this schedule is optimistic, we think we can meet it.

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


Volume-Number: Volume 20, Number 38

From [e-mail]  Sat Jun 23 09:04:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09404; Sat, 23 Jun 90 09:04:34 -0400
Posted-Date: 23 Jun 90 00:03:08 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12273; Sat, 23 Jun 90 08:04:31 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23600; Sat, 23 Jun 90 06:34:45 cdt
From: David J. MacKenzie <[e-mail]>
Newsgroups: comp.std.unix
Subject: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Maryland
Date: 23 Jun 90 00:03:08 GMT
Apparently-To: [e-mail]

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

> From:  [e-mail]

> Might it not be time to "push the envelope" as 1003.4 has done, and specify
> Eric Allman's far superior "parseargs" interface? Getopt really doesn't do
> that much: a command line parser using getopt is only slightly simpler than
> one assembled completely out of a nested loop, and it doesn't do anything
> to help generate usage messages and the like... with the result that usage
> messages that are out of date are not that uncommon, even in system programs.

> Parseargs also helps by providing a system-independent interface, more so
> if you use my extended version of the unix driver routine. That way folks
> who work in other environments will be encouraged to produce programs that
> follow the P1003.2 interface when compiled under POSIX... and POSIX programs
> will fit well into VAX/VMS, MS-DOS, etc...

Parseargs has a lot of problems; I looked at it and discarded it.  It
might provide a superior interface to the programmer, but it doesn't
provide the same interface to the user; that is, it doesn't conform to
the standard Unix option syntax that most programs use (allowing
ganging of multiple single-letter options into a single argument, for
example).  Since getopt is an existing-practice de-facto standard, I
see no justification for trying to push something quite different that
hardly anyone uses as an IEEE standard.  I don't think what 1003.4 is
doing is necessarily a good idea either.  It probably exceeds the
POSIX charter.
--
David J. MacKenzie <[e-mail]> <[e-mail]>

Volume-Number: Volume 20, Number 39

From [e-mail]  Sat Jun 23 09:04:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09464; Sat, 23 Jun 90 09:04:44 -0400
Posted-Date: 22 Jun 90 20:58:21 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12295; Sat, 23 Jun 90 08:04:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23693; Sat, 23 Jun 90 06:41:26 cdt
From: Dave Decot <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX equivalent to <sys/file.h> or <fcntl.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Cupertino
Date: 22 Jun 90 20:58:21 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Dave Decot)

> From:  [e-mail] (Steve Emmerson)
>
> Would some please tell me what header file (or files) is the POSIX-
> equivalent to the BSD <sys/file.h> or the System V <fcntl.h>.
>
> I have the P1003.1 document on order, but it will take 4 to 6 weeks to
> arrive and I need to get on with my work.

With few exceptions, POSIX preferred the System V header name to the BSD
header name when conflicts existed.  This case is no exception:  POSIX
requires that <fcntl.h> define the flag and command macros needed
for open(), creat(), and fcntl().

Dave Decot

Volume-Number: Volume 20, Number 40

From [e-mail]  Sat Jun 23 09:04:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09487; Sat, 23 Jun 90 09:04:53 -0400
Posted-Date: 23 Jun 90 05:54:31 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12308; Sat, 23 Jun 90 08:04:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23749; Sat, 23 Jun 90 06:43:39 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 23 Jun 90 05:54:31 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>Might it not be time to "push the envelope" as 1003.4 has done, and specify
>Eric Allman's far superior "parseargs" interface?

There have actually been MANY such inventions; however, getopt() is the
de facto standard in this area, and thus is appropriate for standardization.

Volume-Number: Volume 20, Number 41

From [e-mail]  Sat Jun 23 09:05:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09546; Sat, 23 Jun 90 09:05:02 -0400
Posted-Date: 23 Jun 90 05:58:43 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12327; Sat, 23 Jun 90 08:04:58 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23805; Sat, 23 Jun 90 06:45:31 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 23 Jun 90 05:58:43 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

-The most detailed discussion involved whether or not files should be
-closed on an Exec.  The Ada binding provides a Start_Process function,
-which is a primitive that safely creates a new process.  In the face
-of Ada tasking, Fork and Exec are unsafe and cannot be used to
-accomplish the results of a Start_Process call.  Once one of these
-unsafe primitives is issued, an application program is no longer under
-the control of the Ada run time system; the operating system is
-involved. ...

Correct me if I'm mistaken, but I thought the specific task of
1003.5 was to provide Ada-language bindings to 1003.1, not to
add functionality.

Volume-Number: Volume 20, Number 42

From [e-mail]  Sat Jun 23 14:45:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19419; Sat, 23 Jun 90 14:45:48 -0400
Posted-Date: 23 Jun 90 12:21:21 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA17434; Sat, 23 Jun 90 10:02:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24904; Sat, 23 Jun 90 09:25:02 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.9: FORTRAN bindings
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Jun 90 12:21:21 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.9: FORTRAN bindings

Michael Hannah <[e-mail]> reports on the April 23-27 meeting
in Salt Lake City, UT:

FORTRAN bindings committee prepares to go to ballot

The FORTRAN bindings committee is preparing the official call for a
ballot group.  Because the POSIX work is all done under the auspices
of the IEEE Technical Committee on Operating Systems Standards
Subcommittee (TCOS-SS), all members of the ballot group must be both
regular IEEE or Computer Society members.  and members of the TCOS-SS
(no extra charge to join).  Non-members may submit informative
ballots, but such ballots cannot count towards the required response
percentage (75%), or percentage of affirmative responses (also 75%)
required for passage of the standard.  [Editor: Institutional
Representatives are exceptions to this rule.  See IEEE 1003.1-1988,
p. 177 for a detailed explanation of the rules.]

For more information, the appropriate membership forms, and
instructions for returning the forms to the proper IEEE offices,
contact the committee chair, John McGrory, at the address listed at
the end of this article.  This information/sign-up packet will be
available by the end of June, but you may contact the chair as soon as
you want your name added to the distribution list.

The formal sign-up period is expected to be August 15 through October
19, 1990.  The ballot period is expected to last from November 9, 1990
through January 4, 1991.  We are especially eager to attract a large,
representative balloting group, and encourage interested individuals
to sign up.  While the views represented on the P1003.9 working group
have been appropriate and varied, the number of active members has
been small (typically, around a dozen).

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings


                - 2 -

Some history

As the committee prepares to go to ballot, it might be of value to
review some of the more sticky issues that the working group has
addressed.  The formal, adopted charter of the committee is to provide
access to the POSIX-defined, standard operating system interface and
environment, directly from the FORTRAN language.  There are two major
issues of scope that bear comment: ``Access to how much of POSIX?''
and ``Which FORTRAN?''

Some POSIX features are easily imagined as useful to a FORTRAN
application (e.g., chmod, exec, etc.); some are less easily imagined
(pick your favorite obscure system call).  It was unclear where to
draw the line, so the committee took the attitude of ensuring access
to all features defined in 1003.1 (IEEE 1003.1-1988, or ISO/IEC 9945-
1:1990).  It seemed clear that full functional access would be
provided by most vendors, so full standardization seemed called for.
Some diehard C language addicts continue to ask, ``Why have any
FORTRAN bindings?'' Although most vendors provide a method of calling
C functions from FORTRAN, they vary from vendor to vendor.  Further,
any library of C routines provided by a vendor to map FORTRAN
constructs to the POSIX defined procedures is bound to differ among
vendors.  The P1003.9 bindings are silent on implementation, so the
FORTRAN subprograms defined in the bindings could be implemented as
just such a library.  The bindings just standardize the interface.
Keeping in mind the POSIX goal of application portability, only a
truly complete FORTRAN binding would provide portability of any
FORTRAN application.

A harder issue was, ``Which FORTRAN?'' Our choices were:

  1.  FORTRAN 77 [ANSI X3.9-1978, ISO 1539-1980 (E)],

  2.  a codification of common extensions/enhancements to FORTRAN 77,
      or

  3.  the revised FORTRAN standard emerging from the ANSI X3J3
      committee --  previously referred to as FORTRAN 8X but now
      called Fortran 90.  (The working group has been delighted to
      have an officially appointed representative of X3J3 as an active
      member.) [Editor: Note that Fortran 90 will finally let us type
      the name of the language without using the caps-lock key.  ``And
      gain is gain, however small.''  --  Robert Browning]
We chose the first.

For FORTRAN 77 vs. Fortran 90, we were swayed by the fact that FORTRAN
77 is currently the only adopted standard.  (Fortran 90 is scheduled
to be adopted as an ANSI standard after P1003.9 goes to ballot.)
Further, FORTRAN-77-based applications are expected to exist for some
years.  Thus, the working group felt that FORTRAN-77-based bindings
would be of value to the user community.  The working group expects to

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings


                - 3 -

develop a new set of bindings, based solely on Fortran 90, after
completion of the FORTRAN 77 bindings (and after the Fortran 90
standard is adopted).  One result of this decision is a subprogram-
naming scheme that reflects the version of the language (e.g., CALL
F77MKDIR(...) ).  This will ensure that there will be no name-space
conflict with similar-purpose subprograms in a future Fortran 90
binding.

An even harder issue, once we decided to base the bindings on FORTRAN
77, was whether to define the bindings as extensions and/or
enhancements to the language itself, or simply as a library of
callable FORTRAN subprograms.  While the latter was finally chosen,
there was considerable argument for the former.  In fact, one
extension to FORTRAN 77 was considered minimally essential.  The
current document requires the language to differentiate external names
unique to 31 characters, even though the FORTRAN 77 standard limits
them to six.  The extension seems harmless.  Fortran 90 specifies
uniqueness to 31 characters and all current FORTRAN 77 compilers
researched provide this extension.  Further, since the list of P1003.9
subprogram names is finite, if necessary, a vendor could provide a
preprocessor to convert these names into unique strings of six
characters.

If the P1003.9 bindings had defined changes to the language itself,
then major missing constructs in the FORTRAN 77 language needed for
easy POSIX access (most notably, structures and pointers) could have
been provided by choosing either the emerging Fortran 90 constructs or
an existing vendor solution.  At first the working group felt that
this might be required for some access features.  However, as we
struggled with each issue, working papers and proposals were
introduced that resolved every one with callable FORTRAN subprograms
(though some might argue about elegance or ease of use).  While we
mostly steered clear of ``ease-of-implementation'' arguments, since we
viewed the FORTRAN 77 bindings as an interim, we felt that vendors
would be quicker to implement a library of subprograms than
modifications to compilers.

A final, hard question of standard scope concerned whether to restrict
the standard to 1003.1, or expand it to general, FORTRAN-application
portability issues, both within and outside the POSIX arena.  Both a
lack of resources and a desire to provide a timely bindings on the
heels of 1003.1 made us decide to limit the scope to 1003.1
functionality.

As other base standards are produced (e.g., 1003.2, 1003.4, etc.), we
expect to construct and ballot bindings for those standards.  For
example, we have worked with P1003.2 in defining a standardized
command to invoke the FORTRAN compiler (after a number of iterations,
now named fort77) which is part of their current draft.  Actual
P1003.9 bindings to 1003.2 might include definitions of additional
utilities of use to FORTRAN applications not mentioned in the base
1003.2 standard (e.g., f77split, f77lint, etc.).

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings


                - 4 -

Another argument against adding features was that many, if not most,
of the problems we saw in portability are solved by new constructs in
Fortran 90.  Many of us felt that as a standards group we should only
provide a minimum set of features for ``perhaps-soon-to-be-obsolete''
FORTRAN 77, and thereby speed up the date for providing full bindings
to the new Fortran 90, which provides more features for application
portability.

How to get involved

If you have strong feelings about these issues, the most effective
avenue to express them at this point is to join the balloting group
being formed.  Nevertheless, if you wish to discuss them before this
you can also directly contact the chair (John McGrory) or me (vice-
chair, Michael Hannah), or join the e-mail discussion group.
Addresses follow:

P1003.9 Chair
John McGrory
Hewlett Packard Co.
Division 2615
19046 Pruneridge Avenue
Cupertino, Ca 95014
[e-mail]

P1003.9 ViceChair
Michael Hannah
Sandia National Labs
Albuquerque, NM 87185
[e-mail]

Un-moderated mailing list:
[e-mail]
To join the list, send request to:
[e-mail]

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings

Volume-Number: Volume 20, Number 43

From [e-mail]  Sat Jun 23 14:44:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19242; Sat, 23 Jun 90 14:44:47 -0400
Posted-Date: 23 Jun 90 12:28:11 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA17482; Sat, 23 Jun 90 10:02:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24922; Sat, 23 Jun 90 09:26:07 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.14: Multiprocessing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Jun 90 12:28:11 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.14: Multiprocessing

Bill Cox <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT: The POSIX Multiprocessing Study Group had its
first official meeting as P1003.14 in Utah, where the SEC approved its
Project Authorization Request (PAR) for a Multiprocessing Execution
Environment Profile.  Multiprocessing systems have become cost-
effective means for providing computing power, but with the advantages
have some specific concerns that need to be addressed at the interface
level.  The goal of this work is to try to make POSIX safe for
multiprocessing; a secondary goal is to try to make POSIX hospitable
for multiprocessing.  POSIX working groups do not necessarily share
the concerns of the implementors and users of multiprocessing systems.

Bob Knighten (Encore) is the Chair, Bill Cox (AT&T UNIX Software
Operation) is Secretary, and Dave Plauger (Alliant) is the Technical
Editor.  Officers must have a commitment of support from their
employers, to ensure that they can attend working group meetings and
devote necessary time to the purposes of the working group.  16 people
attended the group meetings.

People interested in .4A (threads) have tended to be interested in .14
and vice versa.  Many .14 members that have been meeting with
P1003.4/.4A see substantial problems with pthreads in a multiprocessor
environment, and I know at least eight people working on .4A that want
to come work in .14.

The working group designated one official liaison to .4A, who was
joined by two other tentative volunteers.  We will also establish
liaisons with .1, .6, .7, .8, .10, and .12.

During the week, we spent time in three areas.

  1.  We clarified the group's work items, and started work on the
      most important, the Application Environment Profile.  (An AEP
      may specify relevant portions of other POSIX working groups'
      work, make choices where options are permitted, and specify
      behavior that a [draft] standard may have left undefined or
      unspecified.)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June, 1990 Standards Update              IEEE 1003.14: Multiprocessing


                - 2 -

  2.  We discussed current conventional wisdom on multiprocessing.
      The discussions centered around presentations by BBN, Cray,
      Encore, AT&T USO, and Alliant on lessons they've learned.

  3.  We created two small groups.

      The first began work on high-level requirements placed on
      pthreads by multiprocessing.  Attendees included Rick Greer
      (Interactive), Mary Weeks (Sun), and Bill Cox (AT&T USO).

      Here are some requirements we feel strongly about:

         + A library implementation of ``user-level threads'' is
           vitally important.  User-level threads often must be
           multiplexed onto kernel-supported
           objects/processes/threads, largely for performance reasons.
           These kernel-supported objects, etc, are sometimes called
           ``virtual processors,'' because they support an abstraction
           closer to that of a physical processor, with
           interrupts/signals, and a significant amount of state.

         + The formal memory model of P1003.4/D9 section 13.1 must
           apply to .4A.  This model defines the semantics of memory
           interaction that should be preserved in a multithreaded or
           multiprocessing environment.

         + Global threads scheduling makes little sense in a
           multiprocessor, though such scheduling could be useful as a
           hint (Like C's register declarations if you don't have
           enough registers.) Global policy is difficult to implement
           in a multiplexed thread environment.

         + use of attribute structures for mutual exclusion variables
           (in particular, for scheduling hints)

         + Locks shouldn't be opaque, and programmers should be able
           to statically initialize them.  The latter is important so
           that locks can be part of data structures, and not require
           time-consuming dynamic allocation and initialization.

         + There must be only one set of libraries.  There are
           performance reasons to have single-threaded libraries,
           i.e., libraries that are not thread-aware, for a
           uniprocessor or single-threaded applications.  The group
           believes that the cost of maintaining such libraries is
           sufficiently high that a non-reentrant library or set of
           libraries should not be required.

June, 1990 Standards Update              IEEE 1003.14: Multiprocessing


                - 3 -

      The other group began work on the AEP itself.

      Members of this small group, and their responsibilities,
      included

         + Dave Plauger (Alliant) - skeleton for the document,

         + Frank Lawlor (IBM) - checkpoint restart, review, and
           liaison with .10 and .7,

         + James Gibson (BBN) - review and liason with .2,

         + Bob Knighten (Encore) - review and liason with .4, and

         + Tom Weaver (IBM) - review and liason with .1 and .6.

      This group identified several areas of concern:

         + microtasking models

         + checkpoint, snapshots, and core dump format/synchronization

         + a general programming model

         + dividing the ``reading list'' (other P1003 standards and
           drafts)

         + determining focus (are we dealing with portability for
           application writers, users, and/or administrators?)

         + standardizing system services

      A sketch of the planned document includes:

         + reference to TIMS

         + multithreaded applications (.4A)

         + HLL parallel applications (PCF FORTRAN, parallel C)

         + IPC

June, 1990 Standards Update              IEEE 1003.14: Multiprocessing

Volume-Number: Volume 20, Number 44

From [e-mail]  Mon Jun 25 09:20:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27057; Mon, 25 Jun 90 09:20:02 -0400
Posted-Date: 25 Jun 90 10:40:07 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA19014; Mon, 25 Jun 90 08:19:58 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA27185; Mon, 25 Jun 90 06:29:15 cdt
From: Lavalle <[e-mail]>
Newsgroups: world
Subject: comp.mail.maps is an already existing moderated , valid group
Message-Id: <[e-mail]>
Control: newgroup comp.mail.maps moderated
Sender: [e-mail]
Reply-To: [e-mail]
Date: 25 Jun 90 10:40:07 GMT
Apparently-To: [e-mail]

In an earlier control article, samsung!cs.utexas.edu!rutgers!psuvax1!eds1!devon!mbitow!root
requested that comp.mail.maps be changed from moderated to unmoderated

samsung!cs.utexas.edu!rutgers!psuvax1!eds1!devon!mbitow!root says:
Pathalias map distribution group.

This control message is to change it back to moderated, like it should be.

--
News Administrator                       [e-mail]
900 Middlesex Tpk, Bldg. #2, Billerica, MA.  01821
"Know Bull"

From [e-mail]  Wed Jun 27 03:41:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06881; Wed, 27 Jun 90 03:41:58 -0400
Posted-Date: 23 Jun 90 19:27:43 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25125; Wed, 27 Jun 90 02:41:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29691; Tue, 26 Jun 90 17:19:35 cdt
From: D'Arcy J.M. Cain <druid![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: druid![e-mail] (D'Arcy J.M. Cain)
Organization: D'Arcy Cain Consulting, West Hill, Ontario
Date: 23 Jun 90 19:27:43 GMT
Apparently-To: [e-mail]

From:  [e-mail] (D'Arcy J.M. Cain)

In article <[e-mail]> From: David J. MacKenzie <[e-mail]>
>Parseargs has a lot of problems; I looked at it and discarded it.  It
>might provide a superior interface to the programmer, but it doesn't
>provide the same interface to the user; that is, it doesn't conform to
>the standard Unix option syntax that most programs use (allowing
>ganging of multiple single-letter options into a single argument, for
>example).  Since getopt is an existing-practice de-facto standard, I

You might like my getarg function.  I designed it as a replacement for
getopt but in such a way that the user can use it exactly like getopt.
It does however support extra functionality which can be used if the user
is aware of it.  For one thing, options and arguments (files) can be
mixed instead of requiring all options to precede the files.  You can
also initialise the argument list more than once supporting things such
as environment default command lines, arguments from files etc mixed
with arguments from the command line.  I just posted it recently to
alt.sources and I'm interested in getting some feedback on it.

--
D'Arcy J.M. Cain (darcy@druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
[phone]                     |

Volume-Number: Volume 20, Number 45

From [e-mail]  Wed Jun 27 03:42:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06977; Wed, 27 Jun 90 03:42:10 -0400
Posted-Date: 25 Jun 90 16:23:17 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25136; Wed, 27 Jun 90 02:42:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29760; Tue, 26 Jun 90 17:25:05 cdt
From: Dorothy Carney <[e-mail]>
Newsgroups: comp.std.unix
Subject: Directory Standards to expect?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: earth.lerc.nasa.gov![e-mail]
Organization: NASA Lewis Research Center
Date: 25 Jun 90 16:23:17 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Dorothy Carney)

As we manage UNIX workstations, what should we expect from POSIX 1003.7
System Administration regarding directories?  For example, we have heard
about partitioning the directory tree into sharable and non-sharable sets,
with userids to reside in /home in a non-sharable set.  Comments & POSIX
forecasts will be appreciated.

Volume-Number: Volume 20, Number 46

From [e-mail]  Wed Jun 27 03:42:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07081; Wed, 27 Jun 90 03:42:36 -0400
Posted-Date: 25 Jun 90 15:14:32 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25148; Wed, 27 Jun 90 02:42:13 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29825; Tue, 26 Jun 90 17:28:35 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Question about file offsets
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 25 Jun 90 15:14:32 GMT
Apparently-To: [e-mail]

From:  [e-mail]

I am looking for an informal interpretation of IEEE Std 1003.1-1988.

Section 6.5.3.4 specifies that lseek() returns EINVAL if the resulting
file offset would be invalid, but it doesn't say which file offsets
are invalid. The rationale (B.6.5.3) says:

    An illegal file offset that would cause [EINVAL] to be
    returned may be both implementation defined and device
    dependent (for example, memory may have few illegal values).
    A negative file offset may be legal for some devices in
    some implementations.

The standard does not specify an error for I/O operations attempted at
an illegal offset. It _seems_ that the intent is for an offset to be legal
only if some I/O operation is possible at that offset, and for it to be
impossible to set an illegal offset.  This is not changed in the 1990
revision of the standard or in the P1003.1b supplement.

XPG3 is not too clear on this point, but it looks like its intent is to
permit setting illegal file offsets. Optional [ENXIO] errors are added to
all I/O interfaces and an _optional_ [EINVAL] is added to fseek() in the
case that the resulting file offset is negative.

Some implementations do permit lseek() to set "illegal" file offsets,
and some applications take advantage of this.  Does anyone know whether
the original members of the 1003.1 working group intended to permit this?
Does anyone have an implementation that returns [EINVAL] if the
file offset resulting from lseek() is negative, or positive and "too
large"?  Are file offsets represented in your kernel by a signed or an
unsigned type?

Thanks!

    Paul Rabin
    Open Software Foundation
    [e-mail] or uunet!osf.org!rabin
    [phone]

Volume-Number: Volume 20, Number 47

From [e-mail]  Wed Jun 27 03:42:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07040; Wed, 27 Jun 90 03:42:30 -0400
Posted-Date: 24 Jun 90 19:41:00 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25169; Wed, 27 Jun 90 02:42:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29925; Tue, 26 Jun 90 17:38:32 cdt
From: Gordon Burditt <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Re: POSIX equivalent to <sys/file.h> or <fcntl.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Gordon Burditt
Date: 24 Jun 90 19:41:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Gordon Burditt)

>Would some please tell me what header file (or files) is the POSIX-
>equivalent to the BSD <sys/file.h> or the System V <fcntl.h>.

Assuming you're looking for defines like O_RDONLY, the equivalent
is <fcntl.h>.

>(If someone would send me a general header-file mapping, that would be
>great!)

In general, the equivalent of the System V header <x> in POSIX is
either <x> or doesn't exist (isn't standardized).

                        Gordon L. Burditt
                        sneaky.lonestar.org!gordon

Volume-Number: Volume 20, Number 48

From [e-mail]  Wed Jun 27 03:44:00 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07360; Wed, 27 Jun 90 03:44:00 -0400
Posted-Date: 24 Jun 90 20:20:50 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25226; Wed, 27 Jun 90 02:43:55 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29990; Tue, 26 Jun 90 17:42:09 cdt
From: <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 24 Jun 90 20:20:50 GMT
Apparently-To: [e-mail]

From:  [e-mail]

In article <[e-mail]> From: David J. MacKenzie <[e-mail]>
> Parseargs has a lot of problems; I looked at it and discarded it.

On the other hand, I looked at it and fixed them. Check comp.sources.misc.

> It
> might provide a superior interface to the programmer, but it doesn't
> provide the same interface to the user; that is, it doesn't conform to
> the standard Unix option syntax that most programs use (allowing
> ganging of multiple single-letter options into a single argument, for
> example).

Actually, it does do this. You shoulda looked harder. What it doesn't do
is handle variable nubers of arguments, which is one thing I fixed.

> Since getopt is an existing-practice de-facto standard, I
> see no justification for trying to push something quite different that
> hardly anyone uses as an IEEE standard.

Given the things that have already gone in to POSIX, even the almighty
base (such as fgetpos, or banning silent truncation of long file names)
I think that's a bit of a quibble. Getopt pretty much has to stay, I
agree. But parseargs should be considered as a recommended alternative.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>


Volume-Number: Volume 20, Number 49

From [e-mail]  Wed Jun 27 03:44:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07398; Wed, 27 Jun 90 03:44:15 -0400
Posted-Date: 24 Jun 90 01:47:10 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25256; Wed, 27 Jun 90 02:44:11 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00077; Tue, 26 Jun 90 17:51:35 cdt
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]>;
Sender: [e-mail]
Reply-To: [e-mail]
Date: 24 Jun 90 01:47:10 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Shane McCarron)

> From:  Doug Gwyn <[e-mail]>
>
> Correct me if I'm mistaken, but I thought the specific task of
> 1003.5 was to provide Ada-language bindings to 1003.1, not to
> add functionality.

Remember the history of POSIX.1.  We have a standard which should have
been specified in a language independent manner.  If that had been
done, a number of the functions that are in the standard would not be
there, or would be in the C bindings section.  They are convenience
functions for C.  Likewise, there will be convenience functions for
other languages.  Ada is particularly nasty, for all the obvious
reasons.

Someday there will be a language independent 1003.1 specification.  It
will detail the real functionality of the underlying system in such a
way that it will be clear to people doing language bindings which
features they must include.  Until then, there will continue to be
confusion on the subject.

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]

Volume-Number: Volume 20, Number 50

From [e-mail]  Wed Jun 27 16:55:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03432; Wed, 27 Jun 90 16:55:34 -0400
Posted-Date: 27 Jun 90 12:14:08 GMT
Received: by cs.utexas.edu (5.64/1.64)
    id AA26591; Wed, 27 Jun 90 15:55:27 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01608; Wed, 27 Jun 90 13:41:04 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 27 Jun 90 12:14:08 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From: [e-mail] (Shane McCarron)
>Remember the history of POSIX.1.  We have a standard which should have
>been specified in a language independent manner.  If that had been
>done, a number of the functions that are in the standard would not be
>there, or would be in the C bindings section.  They are convenience
>functions for C.  Likewise, there will be convenience functions for
>other languages.  Ada is particularly nasty, for all the obvious
>reasons.

I DO remember the history of 1003.1; I was there!  We most certainly
did NOT set out to create a language-independent standard; C was
specifically chosen for the obvious reason that it was the SOLE
appropriate language for systems-level programming on UNIX, for a
variety of reasons, including the fact that the UNIX kernel has a
marked preference for being fed C data types.

This "language binding" nonsense was foisted off on P1003 in an
attempt to meet ISO guidelines.  I think it must have been adopted
by ISO as the result of Pascal types insisting that they never have
to use any other language.

Clearly, a BASIC, COBOL, or even LISP binding to 1003.1 would be
ludicrous.  I don't know how languages are selected for binding,
but I do know what constitutes a UNIX system interface, and if a
language can support one then that is what it should be given as a
1003.1 binding.

Volume-Number: Volume 20, Number 51

From [e-mail]  Wed Jun 27 16:56:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03583; Wed, 27 Jun 90 16:56:06 -0400
Posted-Date: 27 Jun 90 12:00:46 GMT
Received: by cs.utexas.edu (5.64/1.64)
    id AA26602; Wed, 27 Jun 90 15:55:37 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01678; Wed, 27 Jun 90 13:51:51 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Question about file offsets
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 27 Jun 90 12:00:46 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From: Paul Rabin <[e-mail]>
>Section 6.5.3.4 specifies that lseek() returns EINVAL if the resulting
>file offset would be invalid, but it doesn't say which file offsets
>are invalid.

That's right; it would be overspecification to try to spell out which
file offsets are required to be valid.

>    An illegal file offset that would cause [EINVAL] to be
>    returned may be both implementation defined and device
>    dependent (for example, memory may have few illegal values).
>    A negative file offset may be legal for some devices in
>    some implementations.

The rationale is also right.

>The standard does not specify an error for I/O operations attempted at
>an illegal offset. It _seems_ that the intent is for an offset to be legal
>only if some I/O operation is possible at that offset, and for it to be
>impossible to set an illegal offset.  This is not changed in the 1990
>revision of the standard or in the P1003.1b supplement.

I/O even at a valid offset may nonetheless fail, depending on the type
of file and on various circumstances.  It is certainly the intent of a
successful lseek() that under appropriate circumstances a subsequent
I/O operation MIGHT succeed, but it is not required.  (Consider lseek()
to the end of a non-extendable file.)

>Some implementations do permit lseek() to set "illegal" file offsets,
>and some applications take advantage of this.  Does anyone know whether
>the original members of the 1003.1 working group intended to permit this?

If lseek() reports failure, the attempted offset should not stick.
Otherwise, it should.  The absolute offset may be negative and succeed
for some file types; this was intentional.  For example, on a process
opened as a file a negative offset may be useful to access registers and
the u-area.

>Does anyone have an implementation that returns [EINVAL] if the
>file offset resulting from lseek() is negative, or positive and "too
>large"?  Are file offsets represented in your kernel by a signed or an
>unsigned type?

On 4.3BSD, lseek() to a negative absolute offset on an ordinary file
reports success and returns the (negative) absolute offset.  This is
probably a bug rather than a feature, since I'm sure no valid data can
be returned from the negative bytes of an ordinary file.

Volume-Number: Volume 20, Number 52

From [e-mail]  Thu Jun 28 15:39:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08943; Thu, 28 Jun 90 15:39:10 -0400
Posted-Date: 27 Jun 90 12:41:55 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA13723; Thu, 28 Jun 90 14:39:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05245; Thu, 28 Jun 90 12:17:32 cdt
From: Chip Salzenberg <tct![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: ComDev/TCT, Sarasota, FL
Date: 27 Jun 90 12:41:55 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Chip Salzenberg)

According to [e-mail] (D'Arcy J.M. Cain):
>[Getarg] support[s] extra functionality which can be used if the user
>is aware of it.  For one thing, options and arguments (files) can be
>mixed instead of requiring all options to precede the files.

Consider:

    rm ./-a -b -c -d -e -f

With getopt, all five arguments are filenames.  With getarg, the first
argument is a filename and the rest are options.  This is a feature?
No thanks.

--
Chip Salzenberg at ComDev/TCT     <[e-mail]>, <uunet!ateng!tct!chip>

Volume-Number: Volume 20, Number 53

From [e-mail]  Thu Jun 28 15:39:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08971; Thu, 28 Jun 90 15:39:19 -0400
Posted-Date: 27 Jun 90 15:32:10 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA13736; Thu, 28 Jun 90 14:39:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05324; Thu, 28 Jun 90 12:22:37 cdt
From: Leslie Giles <codex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Codex Corp., Canton MA
Date: 27 Jun 90 15:32:10 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Leslie Giles)

[e-mail] (D'Arcy J.M. Cain) writes:

>You might like my getarg function.  I designed it as a replacement for
>   ... You can
>also initialise the argument list more than once supporting things such
>as environment default command lines, arguments from files etc mixed
>with arguments from the command line.  I just posted it recently to
>alt.sources and I'm interested in getting some feedback on it.

It is also possible to restart getopt() by setting various variables.
I did this in some code to support defaults, as mentioned above.  If anybody
wants to know how to do this then you can mail me (I don't have the code in
front of me at the moment - it'd take time to find it) at...

codex!lezz

Volume-Number: Volume 20, Number 54

From [e-mail]  Thu Jun 28 16:59:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28596; Thu, 28 Jun 90 16:59:49 -0400
Posted-Date: 28 Jun 90 18:20:43 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA19186; Thu, 28 Jun 90 15:59:39 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06448; Thu, 28 Jun 90 15:04:01 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jun 90 18:20:43 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security

An anonymous source reports on the April 23-27 meeting in Salt Lake
City, UT:

Apologia

This is my first and last review as a snitch.  [ Editor: We thank you
for doing it, and hope your circumstances change to allow you to file
more.  ] In it, you'll see no party line.  My views will sometimes be
controversial, and I hope they spark discussion and feedback.  They
represent neither the views of my company nor of its clients -- I'm
submitting this anonymously so no one can misconstrue them as being my
company's -- and they're certainly not meant to represent the
consensus of the 1003.6 Working Group.

I'll put my biases on the table.  I'm a commercial user and commercial
software provider, not a government user, government software
provider, or UNIX vendor.  To some degree, these biases have
influenced the committee, since I've been active in the group since
its inception and attended every 1003.6 meeting.  With that
perspective, let's begin.

1.  Overview

The 1003.6 Working Group is putting together a Department-of-Defense-
inspired version of UNIX.  Our efforts will help vendors sell systems
to the U.S. Government and its contractors.  All our interfaces will
make it easier to evaluate conforming systems at one of the DoD's
Trusted Computer Security Evaluation Criteria (TCSEC) levels.  This is
not inherently bad, but it does sell the commercial and international
communities short.  (More on this later.)

The working group is considering four areas: Discretionary Access
Control (DAC), Mandatory Access Control (MAC), Least Privilege, and
Audit.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 2 -

1.1  Discretionary Access Control

The DAC group's job is hard.  They are devising an Access Control List
(ACL) mechanism that must co-exist with the familiar user/group/other
mechanism.  ACLs are discretionary because the user, not the system,
decides each object's access rights.  The traditional user/group/other
mechanism is also discretionary: file protections are specified by the
user.  ACLs extend this by allowing users to grant different access
permissions to arbitrary lists of named users and groups.  (In other
words, the traditional mechanism is an ACL with exactly three
entries.) Designing an ACL is easy; maintaining compatibility with
chmod, stat, umask, and the file creation mask of creat isn't.

1.2  Mandatory Access Control

MAC is another type of access control mechanism.  All system objects
get a security label and all system users have a security
classification set by the system or the Security Administrator
(Systems Administrator).  Users have no control over this mechanism's
application; objects created by a user of classification X
automatically receive a security label of X.  Only users with
appropriate classifications can access or modify a system object.  (As
a useful, if inexact, analogy, think of the way UNIX automatically
assigns file ownerships.)

The TCSEC security criteria's popularity and widespread acceptance
have given MAC another connotation -- that of a codification of the
familiar, U.S.-government, hierarchical security classifications: Top
Secret, Classified, and Unclassified.  Government policy prohibits
users of a lower classification from viewing work of a higher
classification.  Conversely, users at a high classification may not
make their work available to users at a lower classification: one can
neither ``read up'' nor ``write down.'' There are also compartments
within each classification level, such as NATO, nuclear, DOE, or
project X.  Access requires the proper level and authorization for all
compartments associated with the resource.  The MAC group is defining
interfaces for such a mandatory mechanism.  It's not as confusing as
it sounds, but outside of the DoD it is as useless as it sounds.
(Prove me wrong.  Show me how this DoD policy is useful in a
commercial environment.)

1.3  Least Privilege

The Least Privilege group is eliminating root.  They're creating both
a list of privileges to encompass all of root's special uses, (e.g.,
set-uid to a different user-id, create a directory, create a file
system, override DAC protection) and a mechanism to inherit, assign,
and enable those privileges.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 3 -

1.4  Audit

The Audit group is preparing a standard interface for a logging
mechanism, a standard format for logging records, and a list of system
calls and commands to log.

2.  Standards

At the ISO level, there will be no separate security standard.  Our
work will be merged with the 1003.1 (System Interface), 1003.2
(Commands and Utilities), and 1003.7 (System Administration) work in
the ISO 9945-1, -2, and -3 standards.  This means every conforming
system will include security mechanisms.  I like this.  Do you?

3.  Scope and motivation

All 1003.6 members feel we are making POSIX secure, not merely helping
sell systems to the U.S. government.  Our work is important and
necessary (except, of course, MAC), but I think our focus has been too
narrow.  We included mechanisms for the TCSEC criteria but stopped
there.  We haven't sought out the work of other countries.  We haven't
considered the work being done in international standards bodies such
as ISO and CCITT.  We haven't explicitly considered commercial users.
We've limited ourselves to helping provide TCSEC-conforming systems.
Many of us believe that the TCSEC criteria are good for commercial
applications.  Is that hopeful claim just self-serving?  We don't
know.  I wish eminent computer scientists and researchers had gotten
together to study the needs of commercial users and drawn up an
independent set of commercial security requirements.  But they didn't.

Kevin Murphy, of British Telecom, is the ISO/IEC JTC1/SC22/WG15
security rapporteur -- he formally represents the international
community's concerns and views.  In January, Kevin brought several of
these to the working group's attention, including our TCSEC biases and
lack of attention to ISO activities.  The international set seems to
consider the document's constant references to the TCSEC work
provincial and inconsiderate of other countries' requirements.  They
also feel we should be more aware and accepting of ISO terminology in
the document.  Kevin also says our scope is too limited in the CCITT
X.400 and X.500 areas.

4.  Snowbird

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 4 -

4.1  Plenary

The meeting opened with a short plenary session.  This time, the first
topic of discussion was the progress of the 1003.6 draft document.
Mike Ressler, of Bellcore, accepted the position of technical editor
and brought a new draft of 1003.6, which contained work of all but the
Audit subgroup.  In addition, an electronic copy of the document was
available for the subgroups to modify and update during the meeting.
The technical editor position had been open since October.  No draft
was available during this time, which worried us since it prevented us
from setting any realistic completion date.  With a draft in hand and
a technical editor we now project completion in April, 1991.

Charlie Testa's absence meant we lacked our usual, detailed report on
TRUSIX.  (TRUSIX is a DoD-sponsored organization made up of the
National Computer Security Center, AT&T, and several other companies.)
Rick Sibenaler and Shaun Rovansek, of the NCSC, gave us a brief
update, reporting that the audit rationale will be available at the
July POSIX meeting and that select experts are now reviewing the draft
version of their formal model, which is written in a formal
verification language, INA JO.

Some of the work of TRUSIX augments the work of 1003.6 --  pursuit of
a formal security model and descriptive, top-level specification, and
a mapping between them, for example -- but some overlaps.  I'm still
puzzled over why TRUSIX has pursued audit and DAC mechanisms when
1003.6 is doing the same work.  (Another challenge: can anyone out
there tell me?) To their credit, TRUSIX is accomplishing their goals
much faster than 1003.6.  For example, Charlie reported in January
that the TRUSIX DAC work is already complete.  This speed may be at
the expense of POSIX, since many very good people in both
organizations are forced to split time between the two unnecessarily.

Mike Ressler reported on the networking/administration/security
liaison group, which spends an afternoon at every POSIX meeting
discussing mutual concerns of these three independent working groups.
Here are the liaison group's goals, in areas of our common interest:

   + identify areas of overlapping or missing coverage,

   + provide an interface to ISO, ECMA, CCITT, and other international
     bodies, and

   + exchange ideas and discuss related issues.

Peter Cordsen, of DataCentralen (Denmark), presented Danish security
requirements.  They define three levels of sensitivity, with criminal
data among the most sensitive.  There was no specific comparison to
either the U.S. TCSEC or the emerging European security criteria.
Peter suggested that the security working group begin addressing
authentication, a position that received much support from other
representatives.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 5 -

4.2  Draft work

After the plenary, we worked on the document in subgroups.

4.2.1  Discretionary_Access_Control_(DAC)  The group put together a
new outline for the general and introductory sections of the draft and
rewrote those sections to follow the new outline.  They also resolved
several issues:

   + There will be only one type of default ACL, not the previously
     planned separate types for regular files and directories.

   + A mask entry type has been added to provide a mechanism that
     temporarily overrides all other entries without actually changing
     their values or deleting them from the ACL.  The feature also
     fits nicely with the current plan for ACL interaction with the
     old POSIX permission bits.

   + The user model for both default and actual ACLs will be the same.
     (The internal representations are undefined.) System interfaces
     will be the same, too.  A flag will be added to any interfaces
     that need to be able to distinguish the two.

4.3  Audit

Olin Sibert, of Sun, presented a new, ``compromise'' audit proposal,
based on an earlier one by Kevin Brady, of AT&T, and Doug Steves, of
IBM, which he thought resolved some of the earlier work's problems.
The working group accepted Olin's proposal with minor changes and
incorporated it into Draft 6, which was distributed in the IEEE May
mailing.

4.4  Mandatory Access Control (MAC)

Since Kevin Brady, the MAC chair, was participating in the Audit
discussion, and Chris Hughes, of ICL, the acting chair, was also
absent, Joe Bulger, of NCSC, ran the meeting.  It is still unclear who
will chair the MAC subgroup.

Through the joint efforts of Bellcore and AT&T, the MAC draft had been
translated from a proprietary, word-processor format into the
[n|t]roff + POSIX-macro format required for inclusion in the draft
standard.  The MAC draft's contents had been stable for several
meetings, so the group spent the entire week changing the document.

This group seems to be having the most difficulty getting its job
done.  There doesn't seem to be as much discussion and active
participation in the MAC group as the others.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 6 -

4.5  Privileges

No functional changes were made to the privileges material at this
meeting, but significant changes were made to the rationale.  The
group also firmed up concepts and disambiguated functional
ambiguities.

4.6  Networking, Administration, and Security Liaison

The networking/administration/security liaison group held its second
meeting Wednesday afternoon.  The meeting, chaired by Mike Ressler,
started by reviewing the group's scope and goals.

Since there had been no ISO meeting since the January POSIX meeting,
Yvon Klein, of Group Bull (France), didn't have anything new to say
about ISO's security activities.

As part of the group's continuing efforts to and identify problem
areas, the system administration group and two networking groups gave
presentations on their work.  Steve Carter, of Bellcore, presented the
scope and charter of the system administration group, 1003.7, and
explained their use of an object-oriented paradigm.  Jim Oldroyd, of
the Instruction Set, followed this by presenting the work of 1003.7's
interoperability subgroup.

Kester Fong, of General Motors, gave an overview of the FTAM group.
He left us with the impression that there wasn't much room for
collaboration, but we'll surely need to review the relationship
between the file-system's security semantics and those of FTAM.

Jason Zions, of HP, gave one of the most interesting and aggressive
presentations of the day, on the work of the Transparent File Access
Group, which included a preliminary list of issues that 1003.8 feels
need to be reviewed.

Finally, David Rogers, of ICL (Britain), gave a presentation on the
European security criteria.  He predicted harmonization by June, 1990
of the work of Britain, France, Germany, and Holland.  The European
criteria will define separate levels of functionality and assurance.
There will be ten classes of functionality.  The first five are
hierarchical and are similar to the U.S. Orange-Book criteria; the
remaining five address particular security needs, such as integrity,
availability, and networks.  There are seven classes of assurance.  A
product evaluated under these criteria is likely to receive a rating
from the first five functional classes, one or more of the next five
functional classes, and an assurance rating.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 7 -

4.7  Final Comments

With the short plenary session, the availability of the draft document
in electronic form, and the presence of many lap-top systems to work
on, this meeting was one of our most productive.  The group seems to
have picked up enthusiasm from the knowledge that our work is coming
together and the end is in sight.

June, 1990 Standards Update                      IEEE 1003.6: Security

Volume-Number: Volume 20, Number 55

From [e-mail]  Thu Jun 28 18:15:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24519; Thu, 28 Jun 90 18:15:17 -0400
Posted-Date: 28 Jun 90 18:34:23 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA25755; Thu, 28 Jun 90 17:15:02 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06579; Thu, 28 Jun 90 16:10:59 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jun 90 18:34:23 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.1: System services interface

Paul Rabin <[e-mail]> reports on the April 23-27 meeting in Salt
Lake City, UT:

1.  Introduction

The POSIX 1003.1 working group is the oldest POSIX group, responsible
for specifying general-purpose operating system interfaces for
portable applications.  This group developed the original 1988 POSIX
standard, and is now responsible for writing supplements and revisions
to that standard.  This work includes

   + corrections and clarifications to the 1988 POSIX standard

   + material that was too controversial to handle before

   + new interfaces requested by other POSIX working groups

Like other working groups developing ``base standards,'' the 1003.1
working group is responsible for writing both C language and
language-independent versions of the specifications that it develops.
So far, the group has concentrated on the C language versions, but
there is increasing pressure to make progress on the language-
independent specifications.

The working group recently completed a revision of the 1988 POSIX
standard, and is currently working on a supplement to that revision.

There has been a lot of turnover in the group since the 1988 POSIX
standard was completed, but there are still a few old-timers to
provide continuity.  About 15 people attended the last two meetings.
This seems to be a good size for getting work done.  This is
definitely a technical crowd; check your politics at the door.

For more information about the group and how to participate, contact
the chair, Donn Terry, at [e-mail] or hplabs!hpfcla!donn.

__________

  * UNIXTM is a Registered Trademark of UNIX System Laboratories in
    the United States and other countries.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 2 -

Send comments and proposals to the secretary, Keith Stuck, at
[e-mail].  I've made this report a bit more detailed than
usual in order to give the technical details wider exposure.  New
proposals, and comments on any of the current active proposals or
issues are welcome.

2.  1003.1a Status

1003.1a is the recently completed revision to the 1988 POSIX standard.
No new interfaces or features were introduced, but the text was
revised in several ways.  The main reason for the revision was to
prepare the text for balloting as an ISO standard, so the document had
to be made to look like an ISO standard.  This meant adding ISO
boiler-plate, changing external document references to pretend that
only standards exist, changing internal cross-references so that
chapters are renamed sections, and sections are renamed clauses and
subclauses, changing ``will'' to ``shall,'' etc., ad nauseam.  While
the working group was having fun with all that, they took the
opportunity to do some cleaning up.  They corrected errors, clarified
unclear language, and changed the function synopses to use ANSI C
prototypes.  The group did make one normative change, which was to
specify reserved namespaces.  This will allow implementations and
revisions to the standard to define extensions without breaking
existing, conforming applications.  It's messier than you might think.

After four recirculation ballots, IEEE balloting was completed in
April.  Now it has to get through the ISO balloting process.  See the
recent snitch report on 1003.5 for a description of how IEEE and ISO
balloting is synchronized, and what all of the acronyms mean.

ISO has been balloting 1003.1a as ISO/IEC DIS 9945-1.  After the first
ISO ballot, JTC1 approved 9945-1 for promotion to full IS status.
This approval was overruled by the ISO Central Secretariat on the
grounds that the document format was still not satisfactory (still
haven't caught all of those ``will''s).  Rather than publish the
current document and then immediately revise, ballot, and publish it
again, it was decided to create a new DIS and to start a second round
of ISO balloting.  This will cause a delay in the publication of the
international POSIX standard (and hence also the IEEE POSIX.1
standard).  The U.S. Technical Advisory Group (TAG) is responsible for
generating the U.S. ballot.  Assuming that no normative changes are
introduced by the ISO balloting process, the resulting document will
be published by IEEE as IEEE Std 1003.1-1990.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 3 -

3.  1003.1b Status

Since 1003.1a is now out of IEEE's hands, the working group spent the
Utah meeting working on 1003.1b, the first supplement to 1003.1a.
This will include some corrections and clarifications that didn't make
it into 1003.1a, but will mainly consist of new interfaces and
features.

1003.1b has been in the works for several meetings, so the draft
already contains a lot of material.  The first day was devoted to
revision of the draft, the rest of the week to considering new
proposals.  The previously announced schedule for 1003.1b specified
the Utah meeting as the cutoff date for new proposals.  Unfortunately,
some expected proposals were not received, and some that were received
were not ready for incorporation, so the cutoff was deferred until the
next meeting, in Danvers, Massachusetts.

Draft 2 of 1003.1b was distributed just before the meeting in Utah.
Draft 3 should be available before the Danvers meeting.  1003.1b is
expected to be approved sometime in early 1991, and to be published by
IEEE as a separate supplement to the IEEE Std 1003.1-1990.

3.1  New Features in the Current Draft of 1003.1b

Draft 2 of P1003.1b includes a new data interchange format, and new
interface specifications for symbolic links, environment list access,
and file-tree walking.  These had been proposed and generally accepted
at previous meetings.  Many new issues were raised and discussed.

3.1.1  Symbolic_Links  P1003.1b adds BSD symbolic links to the 1988
POSIX standard as a new required feature.  New interfaces for
symlink(), readlink(), and lstat() are specified, and the definition
of pathname resolution is amended to include the handling of symbolic
links.  Implementations may optionally enforce a limit on the number
of symbolic links that can be tolerated during the resolution of a
single pathname, for instance to detect loops.  The new symbol
{_POSIX_SYMLOOP} is defined to be the minimum value of such a limit.
A new error, [ELOOP], is returned if such a limit is exceeded.
Symbolic links that are encountered in pathname prefixes are always
resolved.  Symbolic links named by the final component of a pathname
will be resolved or not, depending on the particular interface.  By
default, such symbolic links will be resolved, unless specified
otherwise.  The interfaces that will not resolve symbolic links named
by pathname arguments are:

   + readlink()
     If the pathname argument names a symbolic link, the contents of
     the link will be returned.

   + lstat()
     If the pathname argument names a symbolic link, a stat structure
     will be returned for the link itself.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 4 -

   + unlink()
     If the pathname argument names a symbolic link, the link itself
     will be removed.

   + rmdir()
     If the pathname argument names a symbolic link, the link will not
     be followed and the call will fail.

   + open()
     Symbolic links are followed, unless both O_CREAT and O_EXCL are
     set.  If both O_CREAT and O_EXCL are set, and the pathname
     argument names an existing symbolic link, the link will not be
     followed and the call will fail.

   + link()
     If the new pathname names a symbolic link, the link will not be
     followed and the call will fail.  If the old pathname names a
     symbolic link, the link will be followed.  This is the BSD
     behavior.  SVR4.0 does not follow the link in this case, thus
     supporting hard links to symbolic links.  The working group felt
     that the SVR4 behavior unnecessarily restricts implementations
     (for instance, those that do not implement symbolic links with
     inodes), and has much more complex semantics.

   + rename()
     If the old pathname names a symbolic link, the link will not be
     followed.  Instead, the symbolic link itself will be renamed.  If
     the new pathname names a symbolic link, it will not be followed.
     Instead, the symbolic link will be removed, and a new hard link
     will be created naming the file that was previously named by the
     old pathname.

     The 1988 POSIX standard specifies that if the new pathname names
     an existing file, rename() will fail if the new and old pathnames
     do not either both name directories or both name non-directory
     files.  This rule needs to be expanded to include the case of the
     new pathname naming a symbolic link.  Should the rename() call
     fail depending on whether or not the symbolic link named by the
     new pathname itself names a directory or a non-directory file?
     This will be resolved at the next meeting.

Symbolic links are not required to have any attributes other than
their file type and their contents.  This is intended to provide the
simplest semantics and to allow the greatest latitude for
implementations.

3.1.2  Other_BSD_Interfaces  P1003.1b also includes specifications for
the following interfaces:

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 5 -

   + fchmod()

   + fchown()

   + fsync()

   + ftruncate()

3.1.3  Environment_List  The ANSI-C standard defines the getenv()
function to retrieve the value corresponding to a given name in a
program's environment list, but does not specify the implementation or
initialization of that list.  The 1988 POSIX standard specified the
traditional list implementation using the external variable environ,
and specified the initialization of the list by the exec functions.
In an attempt to extend the set of high-level interfaces to the
environment list, and to pave the way for the possible eventual
removal of environ, the working group has included putenv() and
clearenv() interfaces in 1003.1b.  Three problems have been identified
with these high-level interfaces:

   + They cause static data to be shared between the application and
     the implementation.  Neither the application nor the
     implementation can easily manage the storage for environment
     "name=value" strings.

   + They are not robust.  The interactions between the high-level
     interfaces and access via environ is not specified.

   + They can't be easily extended to handle multiple lists.  There is
     no way to copy a list, or to build a new list for execle() or
     execve().

The putenv() and clearenv() interfaces may be removed from 1003.1b at
the next meeting if a revised proposal does not appear.

3.1.4  File_Tree_Walk  The 1003.1 working group promised the 1003.2
group (Shell and Utilities) that a mechanism would be provided for
walking an directory tree of unbounded depth using any given (non-
zero) number of free file descriptors.  The Berkeley folks have
implemented a set of high-level interfaces defined by David Korn of
Bell Labs, and proposed them for inclusion in 1003.1b.  These
interfaces support every option and search order required by the
1003.2 commands.  The 1003.1 group wants a simpler interface suitable
for typical application programs, so Keith Bostic will put the
proposal on a ``weight-reducing diet'' and resubmit it for the next
draft.

The high-level file-tree walk interfaces can be implemented using only
the existing 1003.1 interfaces.  Since 1003.1 does not define a
portable way to save and restore file position for a directory and
cannot hold a file descriptor open for each directory level, the

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 6 -

implementation must read and save all directory entries each time a
new directory is visited.  This requires only a single file descriptor
(or whatever resource is used by by opendir()).  If the underlying
system does provide a way to save and restore file position for
directories, the file-tree walk implementation can use it to reduce
memory consumption.

There was a discussion about whether it is possible (and preferable)
to improve the low-level directory interfaces instead of adding new,
high-level interfaces.  Do the high-level interfaces really add new
functionality for portable applications?  Do they belong with the
low-level operating system interfaces specified in 1003.1?

Walking an unbounded file tree requires an unbounded number of
directory file positions to be supported using a bounded number of
file descriptors.  Either seekdir() and telldir() are needed, or an
unbounded number of opendir()'s must use a bounded number of file
descriptors.  The working group has already rejected seekdir() and
telldir() because they cannot easily be supported on implementations
that use a non-linear directory format.  A prohibition of simple
implementations of opendir() using file descriptors is also likely to
be rejected.

The underlying problem is that the orderedness of directory entries
was implicit in the traditional implementations, but was not made
fully explicit in 1003.1, partly out of a desire to permit alternate
implementations (for instance, b-trees).  As a result, orderedness
must now be imposed by the application.  On a non-linear directory
implementation, if positioning is not supported, even opendir() must
read in the whole directory.

3.1.5  Data-Interchange_Format  The 1988 POSIX standard specified two
data-interchange formats based on existing utilities.  These define
the data-stream encoding of a sequence of files, together with their
pathnames and other attributes.  The first format is based on tar and
encodes files as a stream of 512-byte blocks.  The second format is
based on cpio and encodes files as an unblocked byte stream.

The ISO POSIX group (JTC1/SC22/WG15) pointed out that both of these
formats are incompatible with accepted international and U.S.
standards.  After some arm twisting, the 1003.1 working group agreed
to devise a new data interchange format based on IS 1001: 1986, which
is more or less equivalent to ANS X3.27-1987, the familiar ANSI
labeled tape format.

The current draft of 1003.1b includes the framework for the new
specification, but a lot more work is needed.  Previous meetings
discussed alternate proposals.  The topic has been strangely quiet
lately, considering the confusion that may be expected when it goes to
ballot.  It wasn't discussed at the Utah meeting at all.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 7 -

3.2  {_POSIX_PATH_MAX}: A Clarification

The 1988 POSIX standard included two conflicting statements regarding
{PATH_MAX} and {_POSIX_PATH_MAX}: one said that the null was included
in the count; the other said that the null was excluded.  Traditional
implementations have included the trailing null; some new
implementations have excluded the null.

One alternative or the other had to be endorsed.  The working group
decided that {_POSIX_PATH_MAX} should not include the trailing null,
since specifying this will not break currently conforming
applications.

3.3  Headers and Name-Space Control

Since 1003.1b is adding many new identifiers to the standard, there
was discussion about whether new identifiers should be declared in new
headers, or whether existing headers could be used, with new feature-
test-macros to control visibility of the additional identifiers.  It
was agreed that although both headers and feature-test macros control
identifier visibility, their functions are complementary.  Headers are
appropriately used to divide name-spaces horizontally, by
functionality.  Feature-test macros are appropriately used to divide
name-spaces vertically, by specification level.

With this understanding, the group decided that new identifiers will
be declared in the ``right place.'' A new header will be created only
if no existing header is functionally appropriate.

A new feature-test macro will be specified by 1003.1b and subsequent
revisions: _POSIX_1_SOURCE.  This macro takes ordinal values, starting
with 2 for 1003.1b, and will be incremented by 1 for every subsequent
revision.  If the value is 1, the effect will be the same as if
_POSIX_SOURCE were defined.

There are two changes here.  The new name was used to indicate that
the macro only controls the visibility of identifiers defined in
POSIX.1.  The usage was changed to allow the value to indicate the
particular revision or supplement to the standard, rather than having
to create a new macro each time.  This should simplify the
construction and maintenance of header files.

3.4  Requests

Two requests were made by vendors trying to support POSIX behavior on
non-UNIX file systems:

   + that {_POSIX_LINK_MAX} be reduced from 6 to 2

   + that {_POSIX_PATH_MAX} be reduced from 255 to 252

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 8 -

Both requests were rejected.  Either of these changes could have made
existing conforming applications non-conforming.  Even where the risk
of breaking applications seemed small, the working group was reluctant
to set a precedent without a pretty good rationale to protect them
against similar requests in the future.

3.5  New Proposals

Five proposals for new interfaces were submitted for inclusion in
1003.1b, many of which provoked lively discussion.  Some were
accepted, some were rejected, and others were deferred to allow a
revised proposal to be submitted or to allow more time for
consideration.

3.5.1  seteuid(),_setegid()  Bob Lenk and Mike Karels proposed a set
of changes to the way the effective user and group id's are handled,
in order to provide better support for setuid/setgid programs.

   + Require that all implementations support the functionality of the
     saved user ID and saved group ID.  These process attributes are
     set by the exec functions and by privileged calls to setuid() and
     setgid().

   + Add seteuid() and setegid() as new functions that change only the
     effective user ID and effective group ID, respectively.  A change
     is allowed if the proposed new user/group ID is the same as
     either the real user/group ID or the saved user/group ID.

   + Redefine the {_POSIX_SAVED_IDS} option to apply only to non-
     privileged calls to setuid() and setgid().

This proposal has general support in the working group, and will be
included in the next draft of 1003.1b.

The discussion of this proposal led to a general lament about how
unclear the group model is in the 1988 POSIX standard, perhaps the
result of a hasty marriage between the System V and BSD models.  At
the next meeting, the working group intends to add new text to
P1003.1b to clarify the relation between the effective group ID and
the supplementary group list.

3.5.2  Magnetic_Tape_Support  The 1003.10 working group
(Supercomputing Profiles) proposed new interfaces to support basic
controller functions for magnetic tape drives, based on the ioctl()
commands supported in 4.3BSD.  Although support for these interfaces
would be optional in 1003.1b, the working group decided that the
functions should be further specified according to whether they are:

   + required for all types of tape drives;

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 9 -

   + required only for 9-track tape drives;

   + required only for cartridge tape drives; or

   + optional on all types of tape drives.

The proposal needed further revision, but was generally supported by
the working group.

The submitted proposal also included interfaces for mounting labeled
tape volumes.  These were considered to be inappropriate for inclusion
at this time and will be deferred until a later revision of the
standard.

3.5.3  Checkpoint/Restart  The 1003.10 working group also proposed new
(optional) interfaces for checkpointing and restarting processes.
This proposal is based on two existing implementations.  The
interfaces are intended to protect very-long-running applications from
both scheduled shutdowns and unexpected failures of the system.

The 1003.1 working group was not happy to have to deal with this and
had lots of questions.  Were programming interfaces for portable
applications really needed, or was a command interface sufficient?
How much state needed to be saved in the checkpoint?  What if the
processes depended on additional state information that was not in the
checkpoint, such as file data or the states of other communicating
processes or devices?  In this case, the restart would only be
successful if this additional state had not changed since the
checkpoint.  How could such changes be detected or prevented?  What is
the set of interfaces that an application can use and be sure that it
can be checkpointed and restarted successfully, without dependencies
on additional state?  Should applications have a mechanism for
checkpointing themselves, or for blocking an external request that
they be checkpointed?

Because a checkpoint/restart mechanism will have a major impact on
implementations, and the requirements are not yet clear, the working
group was unwilling to endorse the current proposal.  A task force
made up of representatives of the 1003.1 and 1003.10 working groups
will be created to clarify the requirements and revise the proposal.

This proposal is going to need a lot more discussion, so checkpoint
restart interfaces will almost certainly not be included in P1003.1b,
but they may be adopted in a subsequent revision.

3.5.4  Messaging  The UniForum proposal for new messaging interfaces
has been before the 1003.1 working group for a couple of meetings now.
The proposed interfaces are intended as replacements for the message
catalog interfaces specified in XPG3, and differ from those in several
ways (since the discussion was fairly contentious, I'll try to be
objective):

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 10 -

   + The XPG3 interfaces identify a message by the triple: <catalog
     name, set ID, msg ID>, where catalog name is a file name, and set
     ID and msg ID are integers.  The UniForum interfaces identify a
     message by the triple: <locale name, domain name, message name>,
     where locale name, domain name, and message name are all strings.
     The locale for messages is specified by the new LC_MESSAGES
     category of the locale.  Advocates of the UniForum proposal claim
     that string identifiers are easier to use and are more robust
     against errors during application development and maintenance.

   + In the XPG3 scheme, each message catalog is an ordinary file.
     Message catalogs must be specified by filename and explicitly
     opened before messages can be retrieved.  The NLSPATH environment
     variable provides a search path for message catalogs that can be
     parameterized by (among other things) the language, territory,
     and codeset fields of the LANG environment variable.  In the
     UniForum scheme, groups of messages are specified by an abstract
     ``domain.'' A default domain can be set to control message
     accesses, or the domain can be explicitly specified for an
     individual message access.  Advocates of the UniForum proposal
     claim that the binding of message catalogs to files unnecessarily
     restricts implementations and imposes a more complex interface on
     application developers.

   + The XPG3 interface includes an additional string argument that is
     returned in case no message specified by <set ID, msg ID> can be
     retrieved from the message catalog.  In the UniForum proposal,
     the message name itself is returned if the message cannot be
     found.  Advocates of the UniForum proposal point out that the
     message name string makes a separate, ``default'' message string
     unnecessary.

In addition, the UniForum proposal includes a specification of the
message source file format that differs from the format specified in
XPG3.

   + In the XPG3 format, message strings are implicitly delimited: at
     the beginning by the preceding message ID followed by a single
     space or tab character, and at the end by an unescaped newline.
     In the UniForum format, all strings, including domain names,
     message ID's, and message strings, are explicitly delimited by
     double quotes (").  Adjacent strings separated by white-space
     characters are concatenated.  Advocates of the UniForum proposal
     claim that the new format provides better support for multi-line
     strings and for leading and trailing white-space characters in
     strings.

   + In the XPG3 format, the message ID and its corresponding message
     string are implicitly determined by their position on a source
     line.  In the UniForum format, explicit directives are provided
     for message ID's and message strings.  Advocates of the UniForum

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 11 -

     proposal claim that the new format is extensible.  New attributes
     may be added to message entries, such as screen coordinates or
     font size.

   + The XPG3 format includes directives for deleting individual
     messages and sets of messages, and the associated gencat utility
     takes no switches.  In the UniForum proposal, all deletion
     semantics are provided by switches on the associated gentext
     utility.

There was much discussion of the interfaces; less about the source
file format.  The most divisive issue was whether string message ID's
are preferable to numeric message ID's.  Among those who felt that the
new interfaces are better, there was disagreement about whether the
advantages outweighed the cost of conversion for applications and
implementations based on the XPG3 interfaces.  The rationale
accompanying the UniForum proposal described several ways to convert
applications from the XPG3 interfaces to the proposed new interfaces.

The working group asked X/Open to submit the XPG3 messaging interfaces
as an alternate proposal, since they represent existing practice, and
X/Open has agreed to do so.  X/Open has said that they will follow
POSIX if POSIX endorses a different interface.  The decision regarding
which, if any, messaging proposal to include in 1003.1b will be made
at the POSIX meeting in Danvers.

It's hard to predict the fate of this proposal.  The UniForum proposal
represents the consensus of one of the leading internationalization
working groups and is reported to have some support within X/Open.  On
the other hand, the POSIX working groups are obliged to respect
existing practice.  Watch this space.

3.5.5  /dev/stdin,_/dev/fd/n,_etc.  There was an unofficial proposal
from members of the 1003.2 working group that open() be extended to
recognize the special strings "/dev/stdin", "/dev/stdout",
"/dev/stderr", and "/dev/fd/n", and return a new file descriptor
dup()'ed from STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO, or file
descriptor n, respectively.  This proposal was intended to allow
simplified command line parsing, by eliminating special casing for
``-'' and ``--'' arguments.  The proposal was rejected after a short
exploration of the possible semantics of these pathnames when used
with link(), rename(), etc..

4.  Conclusion

As you can see, there's a lot going on.  Even though most of the
attention has shifted to other working groups, the 1003.1 group is
busy revising and extending the 1988 standard.  The group is small
now, by POSIX standards, but their work is as important as ever.

June, 1990 Standards Update     IEEE 1003.1: System services interface

Volume-Number: Volume 20, Number 56

From [e-mail]  Thu Jun 28 15:43:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10187; Thu, 28 Jun 90 15:43:30 -0400
Posted-Date: 28 Jun 90 15:31:38 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA14099; Thu, 28 Jun 90 14:43:26 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06156; Thu, 28 Jun 90 14:17:14 cdt
From: Mark Brown <[e-mail]>
Newsgroups: comp.std.unix
Subject: UIDs and GIDs
Keywords: versus Networking
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Open Software Foundation
Date: 28 Jun 90 15:31:38 GMT
Apparently-To: [e-mail]

From: [e-mail] (Mark Brown)

In 1003.1, "User ID" is defined as a positive integer (so is GID)...

Also, uid_t is defined as an arithmetic type (same for gid_t).

How does one handle (or can one handle) certain networking conventions that
use a "dummy" user ("nobody") and require a user id of -2 ?

Do these conflict as they seem, or am I missing something (always possible..)

--
Mark Brown   IBM AWD / OSF  |  "The tricky part is common usage."
The Good     [e-mail] |
The Bad     uunet!osf!mbrown|       ---B.2.8.2, "POSIX Symbols",
The Ugly     [phone] |                 POSIX 1003.1-1988

Volume-Number: Volume 20, Number 57

From [e-mail]  Thu Jun 28 18:17:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25268; Thu, 28 Jun 90 18:17:38 -0400
Posted-Date: 28 Jun 90 16:12:39 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA25997; Thu, 28 Jun 90 17:17:33 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06921; Thu, 28 Jun 90 16:43:23 cdt
From: Loren Buck Buchanan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center
Date: 28 Jun 90 16:12:39 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Loren (Buck) Buchanan)

In article <[e-mail]> From:  Doug Gwyn <[e-mail]>
>I DO remember the history of 1003.1; I was there!  We most certainly
>did NOT set out to create a language-independent standard; C was
>specifically chosen for the obvious reason that it was the SOLE
>appropriate language for systems-level programming on UNIX, for a
>variety of reasons, including the fact that the UNIX kernel has a
>marked preference for being fed C data types.

Sometimes you have to make painful changes, so that the future
generations will not have to suffer with "historical artifacts".
This is one place I think the changes should have been made (but
of course I do not know all of the argumentation, compromises, etc.
that passed before the committee came to an agreement.

>This "language binding" nonsense was foisted off on P1003 in an
>attempt to meet ISO guidelines.  I think it must have been adopted
>by ISO as the result of Pascal types insisting that they never have
>to use any other language.

I take exception to "nonsense was foisted".  The reason for language
bindings is so that various different languages can take advantage
of the standard.  Why should PASCALers, FORTRANers, etc. be coerced
into giving up their favorite language.  I regularly use three
different langauges, and I expect that the operating environment I
am working under will not impede my use of these languages.

>Clearly, a BASIC, COBOL, or even LISP binding to 1003.1 would be
>ludicrous.  I don't know how languages are selected for binding,
>but I do know what constitutes a UNIX system interface, and if a
>language can support one then that is what it should be given as a
>1003.1 binding.

Why is it ludicrous,  I think all of them should have bindings to POSIX,
but don't ask me to do the work.  If POSIX is to become truly universal,
then it better support all of them and also RPG II/III, PL/I, Prolog,
MUMPS, and any other general or special purpose language that is in
common use.  How a language is selected is two part, 1) is there a
consensus of the committee that the work should be done, and 2) is
there a fool  ... eh ... er ... uh ... volunteer willing to do the
work of creating and/or being the editor.

I am currently working on the proposed image processing standard, and
how acceptable do you think this standard would be if we ignored
FORTRAN?

B Cing U

Buck

--
Loren Buchanan     | [e-mail]   | #include <std_disclaimer.h>
CSC, 1100 West St. | ...!ames!dftsrv!drax!buck | typedef int by
Laurel, MD 20707   | [phone]            | void where_prohibited(by law){}
CD International lists over 40,000 pop music CDs, collect the whole set.

Volume-Number: Volume 20, Number 57

From [e-mail]  Fri Jun 29 11:02:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02275; Fri, 29 Jun 90 11:02:31 -0400
Posted-Date: 28 Jun 90 22:41:59 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA09552; Fri, 29 Jun 90 10:02:26 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA08679; Fri, 29 Jun 90 09:14:42 cdt
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: P1003.2a/5, Asian Language Support, etc.
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jun 90 22:41:59 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Randall Atkinson)

I've recently received my copy of Draft 5 of the P1003.2a document
and I've got some preliminary thoughts that I think might be worth
mentioning generally.  I want to be explicit in saying that I've
only skimmed the document at this point and some of my concerns might
in fact have been addressed in an area of the document that I haven't
read closely.

1.  I really want the standard to be meaningful in the areas that are
  specified.  A specification that is too watered down and general isn't
  really useful.  By way of example, the effect of the values chosen
  for POSIX2_MAX_NICE and POSIX2_MIN_NICE is to mean that a user can't
  depend on nice or renice doing anything to the job.  The values
  chosen for those two contants should be different and have some
  meaningful (if limited) range to them so that a user can rely on
  the utilities having the same functionality as the existing utilities
  have.

2.  In skimming the draft, there seem to be a number of places where
  there are implicit assumptions that western languages and character
  sets are being used.  There appear at first glance to be several areas
  where support for Asian languages (for example written Chinese) is
  either non-existent or possibly impaired.  This is an understandably
  difficult thing to specify carefully, particularly considering that
  there aren't many involved in the POSIX process who have familiarity
  with non-Western languages.

3.      I support the general constraint of standardising existing
  practice rather than creating new extensions, but would much rather
  see more stringent requirements that utilities either send output to
  the controlling terminal or stdout.  If this isn't specified, the
  existing practice of using piping and shell scripts on all of the
  UNIX \(tm shell utilities is potentially not supported.

4.  Also, I would prefer to see output formats specified wherever possible,
  even if the output format might break some existing implementation
  which uses an incompatible output format.  It is very difficult for
  anyone to safely predict in advance that some utility will never
  be used in a pipe or shell script or have its output processed by
  some other tool (e.g. awk) before being seen by a human.  Hence,
  I tend to disagree with the paragraph on Page X from lines 166-179
  where it states that "exactness of [output] format" has not been
  a primary concern.  Standardisation of the output format is clearly
  within the scope of the present enterprise and enhances the usefulness
  of the resulting standard.


Randall Atkinson
[e-mail]

Volume-Number: Volume 20, Number 59

From [e-mail]  Fri Jun 29 11:03:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02520; Fri, 29 Jun 90 11:03:11 -0400
Posted-Date: 29 Jun 90 02:34:30 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA09622; Fri, 29 Jun 90 10:03:07 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA08761; Fri, 29 Jun 90 09:24:32 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UIDs and GIDs
Keywords: versus Networking
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 29 Jun 90 02:34:30 GMT
Apparently-To: [e-mail]

From:  [e-mail]

I think you take -2 with some degree of poetic license.  Obviously
if your system uses unsigned shorts, call it 0xfffe instead of -2.
The only problem I know is with some System V implementations that
completely disallow uid's with the sign bit on.

Volume-Number: Volume 20, Number 60

From [e-mail]  Fri Jun 29 11:05:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03645; Fri, 29 Jun 90 11:05:40 -0400
Posted-Date: 29 Jun 90 04:23:59 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA09902; Fri, 29 Jun 90 10:05:36 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA08888; Fri, 29 Jun 90 09:34:28 cdt
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: New product: C Portability Verifier
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Mindcraft, Inc.
Date: 29 Jun 90 04:23:59 GMT
Apparently-To: [e-mail]

From: [e-mail] (Chuck Karish)

    The Mindcraft C Portability Verifier is now available.  It should
    prove to be valuable both to software engineers who want to
    write code that meets portability standards (to POSIX.1, POSIX.2,
    ANSI C, base XPG3, many XPG APIs, and locally-developed standards)
    and to software buyers and managers who want to be sure that their
    contractors are providing portable code.

    For more information, see the announcement in comp.newprod or send
    mail to [e-mail] and request a brochure.
--

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

Volume-Number: Volume 20, Number 61

From [e-mail]  Fri Jun 29 11:05:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03694; Fri, 29 Jun 90 11:05:49 -0400
Posted-Date: 29 Jun 90 09:47:07 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA09927; Fri, 29 Jun 90 10:05:44 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09066; Fri, 29 Jun 90 09:48:42 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UIDs and GIDs
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
Date: 29 Jun 90 09:47:07 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

In article <[e-mail]> Mark Brown ([e-mail]) writes:
>In 1003.1, "User ID" is defined as a positive integer (so is GID)...
>
>Also, uid_t is defined as an arithmetic type (same for gid_t).
>
>How does one handle (or can one handle) certain networking conventions that
>use a "dummy" user ("nobody") and require a user id of -2 ?
>
>Do these conflict as they seem, or am I missing something (always possible..)

No, you're spotting something.  Yes, this is a known conflict between
``certain networking conventions'' and POSIX.1.  My guess is that it falls
to POSIX.8 (transparent file access) to unwind.  As POSIX.8 is now defining
two styles of remote file access -- full POSIX.1 semantics (namely better
than ``certain networking conventions''), and highly curtailed semantics
(considerably less than ``certain networking conventions''), one option at
its disposal is to let negative user id's fall down the crack (gulf?)
between the two styles.  An alternative is to weasel out of the conflict by
saying that accesses to remote files by unrecognised users map onto some
unique, unprivileged uid without actually admitting that the uid might be
negative.  Or that they map onto UID_MAX - 1 (except that POSIX.1 does not
have a UID_MAX because uid_t is allowed to be a magic cookie -- albeit a
magic cookie of arithmetic type).  (Incidentally, ISO's central secretariat
has, not ureasonably, asked us for a definition of ``magic cookie''.
Suggestions?)
--
Dominic Dunlop

Volume-Number: Volume 20, Number 62

From [e-mail]  Fri Jun 29 23:15:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00734; Fri, 29 Jun 90 23:15:02 -0400
Posted-Date: 29 Jun 90 19:33:02 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA26638; Fri, 29 Jun 90 22:14:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA11078; Fri, 29 Jun 90 21:28:00 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: UIDs and GIDs, Definition of "Magic Cookie"
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard,     Information Networks Group
Date: 29 Jun 90 19:33:02 GMT
Apparently-To: [e-mail]

From: Jason Zions <[e-mail]>

Dominic Dunlop raises the interesting problem of finding an acceptable,
human-language translatable definition for "Magic Cookie." Might I suggest,
as a starting point,

    An opaque object, or token, of determinate size, whose significance
    is known only to the entity which created it. An entity receiving
    such a token from the generating entity may only make such use of
    the "cookie" as is defined and permitted by the suppliying entity.

As for his comments concerning negative UIDs and the responsibility of
POSIX.8 to do something about it, rest assured that something will indeed
be done. I fear that permitting negative UIDs to fall into a crack will
prove unacceptable; however, I hope the working group will come up with a
better approach.

Right now, we've looked more at administrative solutions to the problem;
that is, requiring some sort of explicit UID mapping mechanism to support a
more sensible mapping of "undesireables" to a local UID. We may do no more
than require the presence of such a mechanism and indicate where in the
semantics of POSIX.8 compliant interfaces such a mechanism becomes
relevant, and defer the definition of the user interface to such a
mechanism to POSIX.7.

(I believe this is the current status of POSIX.8's thinking, based on the
minutes as I've read them. However, my summation should not be considered
an official statement from the working group; read the minutes and talk to
the members for a clearer picture.)


I must, however, take issue with one of Dominic's statements, to wit:

    ...and highly curtailed semantics
    (considerably less than ``certain networking conventions'')

The group is still evolving its understanding of FTAM semantics and
behaviour, the which is driving the "highly curtailed semantics" referred
to. We have by no means concluded that the resulting semantics of the
imputed interface are indeed "highly curtailed", nor are we ready to
conclude that those semantics are "considerably less" than ``certain
networking conventions''. (What a marvelous euphemism!)

In any event, the mapping to a negative UID is a part of some particular
implementations of a remote file access mechanism; many other mechanisms do
not require such a mapping, and in fact many implementations of that
mechanism permit other mappings to be chosen. It is within the scope of
POSIX.8 to, while permitting arbitrary mappings, require that any mapped-to
UID be of type uid_t at all times in all representations. As Dominic
observed, this shouldn't break anything that didn't already deserve to be
broken for other reasons.

Jason Zions
Chair (unconfirmed), IEEE P1003.8 POSIX Networked Transparent File Access

Volume-Number: Volume 20, Number 63

From [e-mail]  Fri Jun 29 23:15:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00803; Fri, 29 Jun 90 23:15:11 -0400
Posted-Date: 29 Jun 90 18:15:05 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA26650; Fri, 29 Jun 90 22:15:08 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA11150; Fri, 29 Jun 90 21:30:59 cdt
From: Sean Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UIDs and GIDs
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Santa Cruz Operation, Inc.
Date: 29 Jun 90 18:15:05 GMT
Apparently-To: [e-mail]

From: [e-mail] (Sean Fagan)

In article <[e-mail]> [e-mail] (Mark Brown) writes:
>In 1003.1, "User ID" is defined as a positive integer (so is GID)...
>Also, uid_t is defined as an arithmetic type (same for gid_t).
>How does one handle (or can one handle) certain networking conventions that
>use a "dummy" user ("nobody") and require a user id of -2 ?
>Do these conflict as they seem, or am I missing something (always possible..)

Certain networking conventions are broken.

uid_t and gid_t have usually (always?) been considered unsigned shorts.
Most architectures let them get away with it, barely.  It is not a good
idea, though.

---
-----------------+
Sean Eric Fagan  | "Just think, IBM and DEC in the same room,
[e-mail]    |      and we did it."
uunet!sco!seanf  |         -- Ken Thompson, quoted by Dennis Ritchie
[phone]   | Any opinions expressed are my own, not my employers'.

Volume-Number: Volume 20, Number 64

From [e-mail]  Sat Jun 30 00:05:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18333; Sat, 30 Jun 90 00:05:58 -0400
Posted-Date: 30 Jun 90 02:28:24 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA28562; Fri, 29 Jun 90 23:05:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12060; Fri, 29 Jun 90 23:12:47 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Jun 90 02:28:24 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

USENIX Standards Watchdog Committee

Jeffrey S. Haemer <[e-mail]> reports on spring-quarter
standards activities

What these reports are about

Reports are done quarterly, for the USENIX Association, by volunteers
from the individual standards committees.  The volunteers are
familiarly known as snitches and the reports as snitch reports.  The
band of snitches and I make up the working committee of the USENIX
Standards Watchdog Committee.  Our job is to let you know about things
going on in the standards arena that might affect your professional
life -- either now or down the road a ways.

We don't yet have active snitches for all the committees and sometimes
have to beat the bushes for new snitches when old ones retire or can't
make a meeting, but the number of groups with active snitches
continues to grow (as, unfortunately, does the number of groups).

We know we currently need snitches in 1003.6 (Security), 1003.11
(Transaction Processing), 1003.13 (Real-time Profile), and nearly all
of the 1200-series POSIX groups, There are probably X3 groups the
USENIX members would like to know about that we don't even know to
look for watchdogs in.  If you're active in any other standards-
related activity that you think you'd like to report on, please drop
me a line.  Andrew Hume's fine report on X3B11.1 is an example of the
kind of submission I'd love to see.

If you have comments or suggestions, or are interested in snitching
for any group, please contact me ([e-mail]) or John
([e-mail]).  If some of the reports make you interested enough
or indignant enough to want to go to a POSIX meeting, or you just want
to talk to me in person, join me at the next set, July 16-20, at the
Sheraton Tara, in Danvers, Massachusetts, just outside of Boston.

The USENIX Standards Watchdog Committee also has both a financial
committee -- Ellie Young, Alan G. Nemeth, and Kirk McKusick (chair);

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June, 1990 Standards Update        USENIX Standards Watchdog Committee


                - 2 -

and a policy committee -- the financial committee plus John S.
Quarterman (chair).

An official statement from John:

     The basic USENIX policy regarding standards is:
          to attempt to prevent standards from prohibiting innovation.
     To do that, we

        + Collect and publish contextual and technical information
          such as the snitch reports that otherwise would be lost in
          committee minutes or rationale appendices or would not be
          written down at all.

        + Encourage appropriate people to get involved in the
          standards process.

        + Hold forums such as Birds of a Feather (BOF) meetings at
          conferences.  We sponsored one workshop on standards.  And
          are cosponsoring another in conjunction with IEEE, UniForum,
          and EUUG.  (Co-chairs are Shane P. McCarron
          <[e-mail]> and Fritz Schulz <[e-mail]>.
          Contact them for details.)

        + Write and present proposals to standards bodies in specific
          areas.

        + Occasionally sponsor White Papers in particularly
          problematical areas, such as IEEE 1003.7 (in 1989).

        + Very occasionally lobby organizations that oversee standards
          bodies regarding new committee, documents, or balloting
          procedures.

        + Starting in mid-1989, USENIX and EUUG (the European UNIX
          systems Users Group) began sponsoring a joint representative
          to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards
          committee.

     There are some things we do not do:

        + Form standards committees.  It's the USENIX Standards
          Watchdog Committee, not the POSIX Watchdog Committee, not
          part of POSIX, and not limited to POSIX.

        + Promote standards.

        + Endorse standards.

June, 1990 Standards Update        USENIX Standards Watchdog Committee


                - 3 -

     Occasionally we may ask snitches to present proposals or argue
     positions on behalf of USENIX.  They are not required to do so
     and cannot do so unless asked by the USENIX Standards Watchdog
     Policy Committee.

     Snitches mostly report.  We also encourage them to recommend
     actions for USENIX to take.

          John S. Quarterman, USENIX Standards Liaison

June, 1990 Standards Update        USENIX Standards Watchdog Committee

Volume-Number: Volume 20, Number 65

From [e-mail]  Sat Jun 30 00:06:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18462; Sat, 30 Jun 90 00:06:21 -0400
Posted-Date: 30 Jun 90 02:42:08 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA28590; Fri, 29 Jun 90 23:06:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12117; Fri, 29 Jun 90 23:14:25 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Jun 90 02:42:08 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

          Jeffrey S. Haemer, [e-mail], Report Editor

Recent Standards Activities

This editorial is an overview of some of the spring-quarter standards
activities covered by the USENIX Standards Watchdog Committee.  A
companion article provides a general overview of the committee itself.

In this article, I've emphasized non-technical issues, which are
unlikely to appear in official minutes and mailings of the standards
committees.  Previously published articles give more detailed, more
technical views on most of these groups' activities.  If my comments
move you to read one of those earlier reports that you wouldn't have
read otherwise, I've served my purpose.  Of course, on reading that
report you may discover the watchdog's opinion differs completely from
mine.

SEC: Standard/Sponsor Executive Committee

The biggest hullabaloo in the POSIX world this quarter came out of the
SEC, the group that approves creation of new committees.  At the April
meeting, in a move to slow the uncontrolled proliferation of POSIX
standards, the institutional representatives (IRs) (one each from
Usenix, UniForum, X/Open, OSF, and UI) recommended two changes in the
Project Authorization Request (PAR) approval process: (1) firm
criteria for PAR approval and group persistence and (2) a PAR-approval
group that had no working-group chairs or co-chairs.  Dale Harris, of
IBM Austin, presented the proposal and immediately took a lot of heat
from the attendees, most of whom are working-group chairs and co-
chairs (Dale isn't an IR, but shared the concerns that motivated the
recommendations and asked to make the presentation.)

The chair, Jim Isaak, created an ad-hoc committee to talk over the
proposal in a less emotional atmosphere.  Consensus when the committee
met was that the problem of proliferating PARs was real, and the only
question was how to fix it.  The group put together a formal set of
criteria for PAR approval (which John Quarterman has posted to
comp.std.unix), which seems to have satisfied everyone on the SEC, and
passed without issue.  The criteria seem to have teeth: at least one
of the Project Authorization Requests presented later (1201.3, UIMS)

__________

  * UNIX is a Registered Trademark of UNIX System Laboratories in the
    United States and other countries.

June, 1990 Standards Update                Recent Standards Activities


                - 2 -

flunked the criteria and was rejected.  Two others (1201.1 and 1201.4
toolkits and Xlib) were deferred.  I suspect (though doubt that any
would admit it) that the proposals would have been submitted and
passed in the absence of the criteria.  In another related up-note,
Tim Baker and Jim Isaak drafted a letter to one group (1224, X.400
API), warning them that they must either prove they're working or
dissolve.

The second of the two suggestions, the creation of a PAR-approval
subcommittee, sank quietly.  The issue will stay submerged so long as
it looks like the SEC is actually using the approved criteria to fix
the problem.  [ Actually, this may not be true.  Watch for developments
at the next meeting, in Danvers, MA in mid-July.  -jsq]

Shane McCarron's column in the July Unix Review covers this area in
more detail.

1003.0: POSIX Guide

Those of you who have read my last two columns will know that I've
taken the position that dot zero is valuable, even if it doesn't get a
lot of measurable work done.  This time, I have to say it looks like
it's also making measurable progress, and may go to mock ballot by its
target of fourth quarter of this year.  To me, the most interesting
dot-zero-related items this quarter are the growing prominence of
profiles, and the mention of dot zero's work in the PAR-approval-
criteria passed by the SEC.

Al Hankinson, the chair, tells me that he thinks dot zero's biggest
contribution has been popularizing profiles -- basically,
application-area-specific lists of pointers to other standards.  This
organizing principle has been adopted not only by the SEC (several of
the POSIX groups are writing profiles), but by NIST (Al's from NIST)
and ISO.  I suspect a lot of other important organizations will fall
in line here.

Nestled among the other criteria for PAR approval, is a requirement
that PAR proposers write a sample description of their group for the
POSIX guide.  Someone questioned why proposers should have to do dot
zero's job for them.  The explanation comes in two pieces.  First, dot
zero doesn't have the resources to be an expert on everything, it has
its hands full just trying to create an overall architecture.  Second,
the proposers aren't supplying what will ultimately go into the POSIX
guide, they're supplying a sample.  The act of drafting that sample
will force each proposer to think hard about where the new group would
fit in the grand scheme, right from the start.  This should help
insure that the guide's architecture really does reflect the rest of
the POSIX effort, and will increase the interest of the other groups
in the details of the guide.

June, 1990 Standards Update                Recent Standards Activities


                - 3 -

1003.1: System services interface

Dot one, the only group that has completed a standard, is in the
throes of completing a second.  Not only has the IEEE updated the
existing standard -- the new version will be IEEE 1003.1-1990 -- ISO
appears on the verge of approving the new version as IS 9945-1.  The
major sticking points currently seem limited to things like format and
layout -- important in the bureaucratic world of international
standards, but inconsequential to the average user.  Speaking of
layout, one wonders whether the new edition and ISO versions will
retain the yellow-green cover that has given the current document its
common name -- the ugly green book.  (I've thought about soaking mine
in Aqua Velva so it can smell like Green Chartreuse, too.)

The interesting issues in the group are raised by the dot-one-b work,
which adds new functionality.  (Read Paul Rabin's snitch report for
the gory details.) The thorniest problem is the messaging work.
Messaging, here, means a mechanism for access to external text and is
unrelated to msgget(), msgop(), msgctl(), or any other message-passing
schemes.  The problem being addressed is how to move all printable
strings out of our programs and into external ``message'' files so
that we can change program output from, say, English to German by
changing an environmental variable.  Other dot-one-b topics, like
symbolic links, are interesting, but less pervasive.  This one will
change the way you write any commercial product that outputs text --
 anything that has printf() statements.

The group is in a quandary.  X/Open has a scheme that has gotten a
little use.  We're not talking three or four years of shake-out, here,
but enough use to lay a claim to the ``existing practice'' label.  On
the other hand, it isn't a very pleasant scheme, and you'd have no
problem coming up with candidate alternatives.  The UniForum
Internationalization Technical Committee presented one at the April
meeting.  It's rumored that X/Open itself may replace its current
scheme with another.  So, what to do?  Changing to a new scheme
ignores existing internationalized applications and codifies an
untried approach.  Blessing the current X/Open scheme freezes
evolution at this early stage and kills any motivation to develop an
easy-to-use alternative.  Not providing any standard makes
internationalized applications (in a couple of years this will mean
any non-throw-away program) non-portable, and requires that we
continue to have to make heavy source-code modifications on every
port -- just what POSIX is supposed to help us get around.

To help you think about the problem, here's the way you'll have to
write the "hello, world" koan using the X/OPEN interfaces:

June, 1990 Standards Update                Recent Standards Activities


                - 4 -

  #include <stdio.h>
  #include <nl_types.h>
  #include <locale.h>
  main()
  {
          nl_catd catd;

          (void)setlocale(LC_ALL, "");
          catd = catopen("hello", 0); /* error checking omitted for brevity */
          printf(catgets(catd, 1, 1,"hello, world\n"));
  }

and using the alternative, proposed UniForum interfaces:

  #include <stdio.h>
  #include <locale.h>
  main()
  {
          (void)setlocale(LC_ALL, "");
          (void)textdomain("hello");
          printf(gettext("hello, world\n"));
  }

I suppose if I had my druthers, I'd like to see a standard interface
that goes even farther than the UniForum proposal: one that adds a
default message catalogue/group (perhaps based on the name of the
program) and a standard, printf-family messaging function to hide the
explicit gettext() call, so the program could look like this:

  #include <stdio.h>
  #include <locale.h>
  #define printf printmsg
  main()
  {
          (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
          printf("hello, world\n");
  }

but that would still be untested innovation.

The weather conditions in Colorado have made this a bonus year for
moths.  Every morning, our bathroom has about forty moths in it.
Stuck in our house, wanting desperately to get out, they fly toward
the only light that they can see and beat themselves to death on the
bathroom window.  I don't know what to tell them, either.

June, 1990 Standards Update                Recent Standards Activities


                - 5 -

1003.2: Shell and utilities

Someone surprised me at the April meeting by asserting that 1003.2
might be an important next target for the FORTRAN binding group.
(``What does that mean?'' I asked stupidly.  ``A standard for a
FORTRAN-shell?'') Perhaps you, like I, just think of dot two as
language-independent utilities.  Yes and no.

First, 1003.2 has over a dozen function calls (e.g., getopt()).  I
believe that most of these should be moved into 1003.1.  System() and
popen(), which assume a shell, might be exceptions, but having
sections of standards documents point at things outside their scope is
not without precedent.  Section 8 of P1003.1-1988 is a section of C-
language extensions, and P1003.5 will depend on the Ada standard.  Why
shouldn't an optional section of dot one depend on dot two?  Perhaps
ISO, already committed to re-grouping and re-numbering the standards,
will fix this.  Perhaps not.  In the meantime, there are functions in
dot two that need FORTRAN and Ada bindings.

Second, the current dot two standard specifies a C compiler.  Dot nine
has already helped dot two name the FORTRAN compiler, and may want to
help dot two add a FORTRAN equivalent of lint (which I've heard called
``flint'').  Dot five may want to provide analogous sorts of help
(though Ada compilers probably already subsume much of lint's
functionality).

Third, more subtle issues arise in providing a portable utilities
environment for programmers in other languages.  Numerical libraries,
like IMSL, are often kept as single, large source files with hundreds,
or even thousands, of routines in a single .f file that compiles into
a single .o file.  Traditional FORTRAN environments provide tools that
allow updating or extraction of single subroutines or functions from
such objects, analogous to the way ar can add or replace single
objects in libraries.  Dot nine may want to provide such a facility in
a FORTRAN binding to dot two.

Anyway, back to the working group.  They're preparing to go to ballot
on the UPE (1003.2a, User Portability Extensions).  The mock ballot
had pretty minimal return, with only ten balloters providing
approximately 500 objections.  Ten isn't very many, but mock ballot
for dot two classic only had twenty-three.  It seems that people won't
vote until they're forced to.

The collection of utilities in 1003.2a is fairly reasonable, with only
a few diversions from historic practice.  A big exception is ps(1),
where historic practice is so heterogeneous that a complete redesign
is possible.  Unfortunately, no strong logical thread links the
1003.2a commands together, so read the ballot with an eye toward
commands that should be added or discarded.

June, 1990 Standards Update                Recent Standards Activities


                - 6 -

A few utilities have already disappeared since the last draft.  Pshar,
an implementation of shar with a lot of bells and whistles, is gone.

Compress/uncompress poses an interesting problem.  Though the utility
is based on clear-cut existing practice, the existing implementation
uses an algorithm that is copyrighted.  Unless the author chooses to
give the algorithm away (as Ritchie dedicated his set-uid patent to
public use), the committee is faced with a hard choice:

   - They can specify only the user interface.  But the purpose of
     these utilities is to ease the cost of file interchange.  What
     good are they without a standard data-interchange format?

   - They can invent a new algorithm.  Does it make sense to use
     something that isn't field-tested or consistent with the versions
     already out there?  (One assumes that the existing version has
     real advantages, otherwise, why would so many people use a
     copyrighted version?)

Expect both the first real ballot of 1003.2a and recirculation of
1003.2 around July.  Note that the recirculation will only let you
object to items changed since the last draft, for all the usual bad
reasons.

1003.3: Test methods

The first part of dot three's work is coming to real closure.  The
last ballot failed, but my guess is that one will pass soon, perhaps
as soon as the end of the year, and we will have a standard for
testing conformance to IEEE 1003.1-1988.

That isn't to say that all is rosy in dot-one testing.  NIST's POSIX
Conformance Test Suite (PCTS) still has plenty of problems:
misinterpretations of dot one, simple timing test problems that cause
tests to run well on 3b2's, but produce bad results on a 30 mips
machine and even real bugs (attempts to read from a tty without first
opening it).  POSIX dot one is far more complex than anything for
which standard test suites have been developed to date.  The PCTS,
with around 2600 tests and 150,000 lines of code, just reflects that
complexity.  An update will be sent to the National Technical
Information Service (NTIS -- also part of the Department Commerce, but
not to be confused with NIST) around the end of September which fixes
all known problems but, with a suite this large, others are likely to
surface later.

By the way, NIST's dot one suite is a driver based on the System V
Verification Suite (SVVS), plus individual tests developed at NIST.
Work has begun on a suite of tests for 1003.2, based, for convenience,
on a suite done originally for IBM by Mindcraft.  It isn't clear how
quickly this work will go.  (For example, the suite can't gel until
dot two does.) For the dot one work, NIST made good use of Research

June, 1990 Standards Update                Recent Standards Activities


                - 7 -

Associates -- people whose services were donated by their corporations
during the test suite development.  Corporations gain an opportunity
to collaborate with NIST and inside knowledge of the test suite.  I
suspect Roger Martin may now be seeking Research Associates for dot
two test suite development.  If you're interested in doing this kind
of work, want to spend some time working in the Washington, D.C. area,
and think your company would sponsor you, his email address is
[e-mail].

By the way, there are a variety of organizational and numbering
changes happening in dot three.  See Doris Lebovits's snitch report
for details.

The Steering Committee on Conformance Testing (SCCT) is the group to
watch.  Though they've evolved out of the dot three effort, they
operate at the TCOS level, and are about to change the way POSIX
standards look.  In response to the ever-increasing burden placed on
the testing committee, the SCCT is going to recommend that groups
producing new standards include in those standards a list of test
assertions to be used in testing them.

Groups that are almost done, like 1003.2, will be grandfathered in.
But what should be done with a group like dot four -- not far enough
along that it has something likely to pass soon, but far enough to
make the addition of major components to its ballot a real problem.
Should this case be treated like language independence?  If so,
perhaps dot four will also be first in providing test assertions.

1003.4: Real-time extensions

The base dot-four document has gone to ballot, and the ensuing process
looks like it may be pretty bloody.  Fifty-seven percent of the group
voted against the current version.  (One member speculated privately
that this meant forty-three percent of the balloting group didn't read
it.) Twenty-two percent of the group (nearly half of those voting
against) subscribed to all or part of a common reference ballot, which
would require that entire chapters of the document be completely
reworked, replaced, or discarded.  Subscribers to this common
reference ballot included employees of Unix International and the Open
Software Foundation, of Carnegie-Mellon University and the University
of California at Berkeley, and of Sun Microsystems and Hewlett-
Packard.  (USENIX did not ballot similarly, but only because of lack
of time.) Some of these organizations have never before agreed on the
day of the week, let alone the semantics of system calls.  But then,
isn't bringing the industry together one goal of POSIX?

Still, the document has not been returned to the working group by the
technical editors, so we can assume they feel hopeful about resolving
all the objections.  Some of this hope may come from the miracle of
formality.  I've heard that over half of the common reference ballot
could be declared non-responsive, which means that there's no

June, 1990 Standards Update                Recent Standards Activities


                - 8 -

obligation to address over half the concerns.

The threads work appears to enjoy a more positive consensus.  At least
two interesting alternatives to the current proposal surfaced at the
April meeting, but following a lot of discussion, the existing
proposal stood largely unchanged.  I predict that the threads work
which will go to ballot after the base, dot four document, will be
approved before it.  John Gertwagen, dot four snitch and chair of
UniForum's real-time technical committee, has bet me a beer that I'm
wrong.

1003.5: Ada bindings and 1003.9: FORTRAN-77 bindings

These groups are coming to the same place at the same time.  Both are
going to ballot and seem likely to pass quickly.  In each case, the
major focus is shifting from technical issues to the standards process
and its rules: forming balloting groups, relations with ISO, future
directions, and so on.

Here's your chance to do a good deed without much work.  Stop reading,
call someone you know who would be interested in these standards, and
give them the name of someone on the committee who can put them into
the balloting group.  (If nothing else, point them at our snitches for
this quarter: Jayne Baker [e-mail], for dot five, and
Michael Hannah [e-mail], for dot nine.) They'll get both a
chance to see the standard that's about to land on top of their work
and a chance to object to anything that's slipped into the standard
that doesn't make sense.  The more the merrier on this one, and they
don't have to go to any committee meetings.  I've already called a
couple of friends of mine at FORTRAN-oriented companies; both were
pleased to hear about 1003.9, and eager to read and comment on the
proposed standard.

Next up for both groups, after these standards pass, is negotiating
the IEEE standard through the shoals of ISO, both getting and staying
in sync with the various versions and updates of the base standard
(1003.1a, 1003.1b, and 9945-1), and language bindings to other
standards, like 1003.2 and 1003.4.  (See my earlier discussion of dot
two.) Notice that they also have the burden of tracking their own
language standards.  At least in the case of 1003.9, this probably
means eventually having to think about a binding to X3J3 (Fortran 90).

1003.6: Security

This group has filled the long-vacant post of technical editor, and,
so, is finally back in the standards business.  In any organization
whose ultimate product is to be a document, the technical editor is a
key person.  [We pause here to allow readers to make some obligatory
cheap shot about editors.] This is certainly the case in the POSIX
groups, where the technical editors sometimes actually write large
fractions of the final document, albeit under the direction of the

June, 1990 Standards Update                Recent Standards Activities


                - 9 -

working group.

I'm about to post the dot six snitch report, and don't want to give
any of it away, but will note that it's strongly opinionated and
challenges readers to find any non-DoD use for Mandatory Access
Control, one of the half-dozen areas that they're standardizing.

1003.7: System administration

This group has to solve two problems at different levels at the same
time.  On the one hand, it's creating an object-oriented definition of
system administration.  This high-level approach encapsulates the
detailed implementation of objects interesting to the system
administrator (user, file system, etc.), so that everyone can see them
in the same way on a heterogeneous environment.  On the other hand,
the protocol for sending messages to these objects must be specified
in detail.  If it isn't, manufacturers won't be able to create
interoperable systems.

The group as a whole continues to get complaints about its doing
research-by-committee.  It's not even pretending to standardize
existing practice.  I have mixed feelings about this, but am
unreservedly nervous that some of the solutions being contemplated
aren't even UNIX-like.  For example, the group has tentatively
proposed the unusual syntax object action.  Command names will be
names of objects, and the things to be done to them will be arguments.
This bothers me (and others) for two reasons.  First, this confuses
syntax with semantics.  You can have the message name first and still
be object-oriented; look at C++.  Second, it reverses the traditional,
UNIX verb-noun arrangement: mount filesystem becomes filesystem mount.
This flies in the face of the few existing practices everyone agrees
on.  I worry that these problems, and the resulting inconsistencies
between system administration commands and other utilities, will
confuse users.  I have a recurring nightmare of a long line of new
employees outside my door, all come to complain that I've forgotten to
mark one of my device objects, /dev/null, executable.

With no existing practice to provide a reality-check, the group faces
an uphill struggle.  If you're an object-oriented maven with a yen to
do something useful, take a look at what this group is doing, then
implement some of it and see if it makes sense.  Look at it this way:
by the time the standard becomes reality, you'll have a product, ready
to ship.

1003.10: Supercomputing

This group is working on things many of us us old-timers thought we
had seen the last of: batch processing and checkpointing.  The
supercomputing community, condemned forever to live on the edge of
what computers can accomplish, is forced into the same approaches we
used back when computer cycles were harder to come by than programmer
cycles, and machines were less reliable than software.

June, 1990 Standards Update                Recent Standards Activities


                - 10 -

Supercomputers run programs that can't be run on less powerful
computers because of their massive resource requirements
(cpu/memory/io).  They need batch processing and checkpointing because
many of them are so resource-intensive that they even run for a long
time on supercomputers.  Nevertheless, the supercomputing community is
not the only group that would benefit from standardization in these
areas.  (See, for example, my comments on dot fourteen.) Even people
who have (or wish to have) long-running jobs on workstations, share
some of the same needs for batch processing and checkpointing.

Karen Sheaffer, the chair of dot ten, had no trouble quickly recasting
the group's proposal for a batch PAR into a proposal that passed the
SEC's PAR-approval criteria.  The group is modeling a batch proposal
after existing practice, and things seem to be going smoothly.

Checkpointing, on the other hand, isn't faring as well.  People who
program supercomputers need to have a way to snapshot jobs in a way
that lets them restart the jobs at that point later.  Think, for
example, of a job that needs to run for longer than a machine's mean-
time-to-failure.  Or a job that runs for just a little longer than
your grant money lasts.  There are existing, proprietary schemes in
the supercomputing world, but none that's portable.  The consensus is
that a portable mechanism would be useful and that support for
checkpointing should be added to the dot one standard.  The group
brought a proposal to dot one b, but it was rejected for reasons
detailed in Paul Rabin's dot one report.  Indeed, the last I heard,
dot-one folks were suggesting that dot ten propose interfaces that
would be called from within the program to be checkpointed.  While
this may seem to the dot-one folks like the most practical approach,
it seems to me to be searching under the lamp-post for your keys
because that's where the light's brightest.  Users need to be able to
point to a job that's run longer than anticipated and say,
``Checkpoint this, please.'' Requiring source-code modification to
accomplish this is not only unrealistic, it's un-UNIX-like.  (A
helpful person looking over my shoulder has just pointed out that the
lawyers have declared ``UNIX'' an adjective, and I should say
something like ``un-UNIX-system-like'' instead.  He is, of course,
correct.) Whatever the interface is, it simply must provide a way to
let a user point at another process and say, ``Snapshot it,'' just as
we can stop a running job with job control.

1003.12: Protocol-independent interfaces

This group is still working on two separate interfaces to the network:
Simple Network Interface (SNI) and Detailed Network Interface (DNI).
The January meeting raised the possibility that the group would
coalesce these into a single scheme, but that scheme seems not to have
materialized.  DNI will provide a familiar socket- or XTI/TLI-like
interface to networks, while SNI will provide a simpler, stdio-like

June, 1990 Standards Update                Recent Standards Activities


                - 11 -

interface for programs that don't need the level of control that DNI
will provide.  The challenge of SNI is to make something that's simple
but not so crippled that it's useless.  The challenge of DNI is to
negotiate the fine line between the two competing, existing practices.
The group has already decided not to use either sockets or XTI, and is
looking at requirements for the replacement.  Our snitch, Andy
Nicholson, challenged readers to find a reason not to make DNI
endpoints POSIX file descriptors, but has seen no takers.

1003.14: Multiprocessing

The multiprocessing group, which had been meeting as sort of an ad-hoc
spin-off of the real-time group, was given PAR approval at the April
meeting as 1003.16 but quickly renamed 1003.14 for administrative
reasons.  They're currently going through the standard set of jobs
that new groups have to accomplish, including figuring out what tasks
need to be accomplished, whom to delegate them to, and how to attract
enough working-group members to get everything done.  If you want to
get in on the ground floor of the multiprocessing standard, come to
Danvers and volunteer to do something.

One thing that needs to be done is liaison work with other committees,
many of which are attacking problems that bear on multiprocessors as
well.  One example is dot ten's checkpointing work, which I talked
about earlier, Checkpointing is both of direct interest to dot
fourteen, and is analogous to several other problems the group would
like to address.  (A side-effect of the PAR proliferation problem
mentioned earlier is that inter-group coordination efforts go up as
the square of the number of groups.)

1201: Windows, sort of

Okay, as a review, we went into the Utah meeting with one official
group, 1201, and four unofficial groups preparing PARs:

  1.  1201.1: Application toolkit

  2.  1201.2: Recommended Practice for Driveability/User Portability

  3.  1201.3: User Interface Management Systems

  4.  1201.4: Xlib

By the end of the week, one PAR had been shot down (1201.3), one
approved (1201.2), and two remained unsubmitted.

The 1201.4 par was deferred because the X consortium says Xlib is
about to change enough that we don't want to standardize the existing
version.  I'll ask, ``If it's still changing this fast, do we want to
even standardize on the next version?'' The 1201.1 PAR was deferred
because the group hasn't agreed on what it wants to do.  At the

June, 1990 Standards Update                Recent Standards Activities


                - 12 -

beginning of the week, the two major camps (OSF/Motif and OPEN LOOK)*
had agreed to try to merge the two interfaces.  By mid-week, they
wouldn't even sit at the same table.  That they'd struck off in an
alternative, compromise direction by the end of the week speaks
extremely highly of all involved.  What the group's looking at now is
a toolkit at the level of XVT**: a layer over all of the current,
competing technologies that would provide portability without
invalidating any existing applications.  This seems like just the
right approach.  (I have to say this because I suggested it in an
editorial about six months ago.)

The 1201.3 PAR was rejected.  Actually, 1201 as a whole voted not to
submit it, but the people working on it felt strongly enough that they
submitted it anyway.  The SEC's consensus was that the field wasn't
mature enough to warrant even a recommended practice, but the work
should continue, perhaps as a UniForum Technical Committee.  The study
group countered that it was important to set a standard before there
were competing technologies, and that none of the attendees sponsoring
companies would be willing to foot the bill for their work within
anything but a standards body.  The arguments weren't persuasive.

The 1201.2 PAR, in contrast, sailed through.  What's interesting about
this work is that it won't be an API standard.  A fair fraction of the
committee members are human-factors people, and the person presenting
the PAR convinced the SEC that there is now enough consensus in this
area that a standard is appropriate.  I'm willing to believe this, but
I think that stretching the net of the IEEE's Technical Committee on
Operating Systems so wide that it takes in a human-factors standard
for windowing systems is overreaching.

X3

There are other ANSI-accredited standards-sponsoring bodies in the
U.S. besides the IEEE.  The best known in our field is the Computer
Business Equipment Manufacturers' Association (CBEMA), which sponsors
the X3 efforts, recently including X3J11, the ANSI-C standards
committee.  X3J11's job has wound down; Doug Gwyn tells me that
there's so little happening of general interest that it isn't worth a
report.  Still, there's plenty going on in the X3 world.  One example
is X3B11, which is developing a standard for file systems on optical
disks.  Though this seems specialized, Andrew Hume suggests in his

__________

  * OSF/Motif is a Registered Trademark of the Open Software
    Foundation.
    OPEN LOOK is a Registered Trademark of AT&T.

 ** XVT is a trademark of XVT Software Inc.

June, 1990 Standards Update                Recent Standards Activities


                - 13 -

report that this work may eventually evolve into a standards effort
for file systems on any read-write mass storage device.  See the dot-
four common reference ballot for the kind of feelings new file-system
standards bring out.

I encourage anyone out there on an X3 committee who thinks the
committee could use more user exposure and input to file a report.
For example, Doug Gwyn suggests that there is enough activity in the
C++ standards world to merit a look.  If anyone out there wants to
volunteer a report, I'd love to see it.

June, 1990 Standards Update                Recent Standards Activities

Volume-Number: Volume 20, Number 66

From [e-mail]  Sat Jun 30 01:21:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08761; Sat, 30 Jun 90 01:21:03 -0400
Posted-Date: 29 Jun 90 21:12:26 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05276; Sat, 30 Jun 90 00:20:58 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12252; Sat, 30 Jun 90 00:14:40 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 29 Jun 90 21:12:26 GMT
Apparently-To: [e-mail]

From:  Jason Zions <[e-mail]>

> Conversely, users at a high classification may not make their work
> available to users at a lower classification: one can neither ``read up''
> nor ``write down.'' There are also compartments within each
> classification level, such as NATO, nuclear, DOE, or project X.  Access
> requires the proper level and authorization for all compartments
> associated with the resource.  The MAC group is defining interfaces for
> such a mandatory mechanism.  It's not as confusing as it sounds, but
> outside of the DoD it is as useless as it sounds.  (Prove me wrong.  Show
> me how this DoD policy is useful in a commercial environment.)

Both compartmentalization and classification have commercial applications,
but I'm not certain those applications justify the cost and pain.

Compartmentalization: Large organizations frequently pursue strategies and
practices in the course of daily business that seem, well, contradictory.
Things like negotiating with arch-rival companies to sell each of them
exclusive rights to a particular technology; at some point, when the
higher-ups figure one of the two deals is superior, the other "falls
through". For the sake of verisimilitude, one might wish to
compartmentalize both negotiation efforts from each other and from the rest
of the company on a "need-to-know" basis.

One might wish to compartmentalize ones research labs from ones marketing
people to prevent the marketing of "futures"; similarly, separating R&D
from support organizations can help prevent leakage.

All of these can be accomplished by a Simple Matter Of Policy; it is a
known phenomena, though, that the large the company the higher the
probability of leakage, regardless of policy. MAC can help.

Classification: Certain kinds of information are frequently required by law
to be controlled with respect to dissemination internally; data related to
profit and loss, stock exchange filings, personnel data, etc. Many
companies today forbid the electronic storage of such restricted
information, and they distribute it by means of printed copies, numbered
and signed for, burn-before-reading. It'd be nice to be able to store that
stuff on-line, transmit it electronically, while ensuring that those who
are not permitted by law to see the information cannot see it.

Again, SMOP can accomplish this; however, it's a lot easier to prove
someone is or is not an "insider" in the technical sense of the term by
showing whether or not they hda access to the relevant data, and by
recourse to an audit trail.

 - - - -

> Jason Zions, of HP, gave one of the most interesting and aggressive
                                                           ^^^^^^^^^^
> presentations of the day, on the work of the Transparent File Access
> Group, which included a preliminary list of issues that 1003.8 feels
> need to be reviewed.

Really? (wince)  Musta been a bad day. My apologies to all.

Jason Zions
Chair, 1003.8

Volume-Number: Volume 20, Number 67

From [e-mail]  Sat Jun 30 01:21:13 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08804; Sat, 30 Jun 90 01:21:13 -0400
Posted-Date: 29 Jun 90 22:09:32 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05290; Sat, 30 Jun 90 00:21:08 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12313; Sat, 30 Jun 90 00:17:25 cdt
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Mandatory Access Controls in the commercial world
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 29 Jun 90 22:09:32 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Randall Atkinson)

% The TCSEC security criteria's popularity and widespread acceptance
% have given MAC another connotation -- that of a codification of the
% familiar, U.S.-government, hierarchical security classifications: Top
% Secret, Classified, and Unclassified.  Government policy prohibits
% users of a lower classification from viewing work of a higher
% classification.  Conversely, users at a high classification may not
% make their work available to users at a lower classification: one can
% neither ``read up'' nor ``write down.'' There are also compartments
% within each classification level, such as NATO, nuclear, DOE, or
% project X.  Access requires the proper level and authorization for all
% compartments associated with the resource.  The MAC group is defining
% interfaces for such a mandatory mechanism.  It's not as confusing as
% it sounds, but outside of the DoD it is as useless as it sounds.

I disagree.  The mechanisms described here are indeed useful
in the commercial world.  For example, an insurance company happens to
own and operate both a bank and a savings & loan and a lot of customers
of the banks are owner-members of the insurance firm.  The firm is legally
obligated not to permit the bank/s&l to have access to information on
a customers insurance information or the fact that he/she is a member-owner
of the insurance firm without explicit written permission from the individual
whose records we are concerned with here.  But the insurance agency may
legally access the information in the bank/s&l on its customers.  This
is analgous to the workers at the insurance firm being in a different
compartment than the workers at the bank or s&l.  Similarly, a bank teller
would normally be able to access one level of information and a loan officer
or branch manager a different level of information.  Please note
that my example is real-world rather than one I'm making up.

Similarly, firms engaged in product development of one sort or another,
for example making computer systems, frequently have projects with different
sensitivites and areas of access.  Often the goal is deliberately
restrict and compartmentalise information about actual costs or profit
margin or future plans or two groups with competing approaches to solving
customer needs.  The management will find it useful to control information
access both horizontally and vertically.

Certainly the restrictions on write-down and read-up are essential
to having a viable security system.  It is possible and desirable to
talk in terms of having both vertical levels of access and horizontal
compartmentalisation without actually using DoD's official classifications
whatever they might be.  I trust the POSIX draft doesn't talk in terms
of Unclassified, Secret, and Top Secret as that would be inappropriate.


Randall Atkinson
[e-mail]
Opinions are those of the author.

Volume-Number: Volume 20, Number 68

From [e-mail]  Sat Jun 30 01:21:24 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08840; Sat, 30 Jun 90 01:21:24 -0400
Posted-Date: 29 Jun 90 21:33:13 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05298; Sat, 30 Jun 90 00:21:19 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12387; Sat, 30 Jun 90 00:20:56 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 29 Jun 90 21:33:13 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

>There was a discussion about whether it is possible (and preferable)
>to improve the low-level directory interfaces instead of adding new,
>high-level interfaces.  Do the high-level interfaces really add new
>functionality for portable applications?  Do they belong with the
>low-level operating system interfaces specified in 1003.1?

No, definitely not.  However, they would be appropriate at the 1003.2
level.  Note that 1003.2 implementations are not constrained to use
only 1003.1 facilities, so the fact that it's hard to implement tree
walkers right using the existing 1003.1 directory access functions is
no argument against defining tree walkers as part of a higher level.

>The ISO POSIX group (JTC1/SC22/WG15) pointed out that both of these
>[tar, cpio] formats are incompatible with accepted international and U.S.
>standards.  After some arm twisting, the 1003.1 working group agreed
>to devise a new data interchange format based on IS 1001: 1986, which
>is more or less equivalent to ANS X3.27-1987, the familiar ANSI
>labeled tape format.

The ANSI magtape format is simply inappropriate.  UNIX archives were
designed to be single files, making it simple to transport them by
means other than magnetic tape.  In this modern networked world, for
the most part magnetic tape is an anachronism.  Any archive format
standard for UNIX should not depend on the archive supporting
multiple files, tape marks, or any other non-UNIX concept.

It is to the credit of UNIX's original designers that they did NOT
blindly adopt existing standards when they were technically inferior.
Let's not make the POSIX standards impose conventional-think upon
UNIX environments..

Volume-Number: Volume 20, Number 69

From [e-mail]  Sat Jun 30 01:21:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08911; Sat, 30 Jun 90 01:21:36 -0400
Posted-Date: 29 Jun 90 21:36:16 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05306; Sat, 30 Jun 90 00:21:30 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12443; Sat, 30 Jun 90 00:23:40 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UIDs and GIDs
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 29 Jun 90 21:36:16 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <[e-mail]>

In article <[e-mail]> From: [e-mail] (Mark Brown)
>How does one handle (or can one handle) certain networking conventions that
>use a "dummy" user ("nobody") and require a user id of -2 ?

These are not POSIX-conforming.
NFS was determined to not be POSIX-conformant in several ways
during 1003.1 deliberations.  Our consensus was that we shouldn't
mess up UNIX standards to accommodate such clear violations of
UNIX conventions as the use of negative UIDs.

It is possible that you can get away with using UID 65534 instead
of -2.

Volume-Number: Volume 20, Number 70

From [e-mail]  Sat Jun 30 01:21:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08940; Sat, 30 Jun 90 01:21:45 -0400
Posted-Date: 29 Jun 90 21:46:11 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05326; Sat, 30 Jun 90 00:21:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12500; Sat, 30 Jun 90 00:26:28 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 29 Jun 90 21:46:11 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From: [e-mail] (Loren Buchanan)
>Why should PASCALers, FORTRANers, etc. be coerced into giving up
>their favorite language.  I regularly use three different langauges,
>and I expect that the operating environment I am working under will
>not impede my use of these languages.

That's not what we're talking about.  Pascal and Fortran can be
fully implemented in a UNIX environment.  You are not being asked
to "give up" those languages.  What I am saying is that you should
not insist on using a language in an application domain for which
it is ill suited.  Fortran is not an appropriate choice for systems
programming applications in a UNIX environment.  While it is
perhaps possible to devise a complete 1003.1 binding for Fortran
(I suspect it wouldn't be possible for BASIC), there is no real need
to do so.  On the other end of the spectrum, Ada has its own notions
of tasking that don't mesh well with UNIX's process model.  Since
the promulgators of Ada have insisted for years that Ada programs
must not use extensions to the language, I suggest that holding them
to their word would have been quite appropriate.

Volume-Number: Volume 20, Number 71

From [e-mail]  Sat Jun 30 01:21:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08963; Sat, 30 Jun 90 01:21:55 -0400
Posted-Date: 29 Jun 90 19:40:47 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05335; Sat, 30 Jun 90 00:21:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12558; Sat, 30 Jun 90 00:29:34 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 29 Jun 90 19:40:47 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From:  <[e-mail]> (anonymous 1003.6 report)
> At the ISO level, there will be no separate security standard. ...
> This means every conforming
> system will include security mechanisms.

You mean, "will include DoD-style security mechanisms". The somewhat
simple-minded approach UNIX has had in the past has been remarkably
successful, considering.

> I like this.  Do you?

Only if it's possible to turn everything off and go back to /etc/passwd
and /etc/shadow, and a superuser. That way when something goes wrong you'll
be able to boot from tape or floppy, edit a couple of files, and recover
the system.

Because something *will* go wrong.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 72

From [e-mail]  Sat Jun 30 15:01:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13140; Sat, 30 Jun 90 15:01:52 -0400
Posted-Date: 29 Jun 90 14:07:42 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA24409; Sat, 30 Jun 90 11:18:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13336; Sat, 30 Jun 90 10:31:00 cdt
From: D'Arcy J.M. Cain <druid![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: druid![e-mail] (D'Arcy J.M. Cain)
Organization: D'Arcy Cain Consulting, West Hill, Ontario
Date: 29 Jun 90 14:07:42 GMT
Apparently-To: [e-mail]

From:  [e-mail] (D'Arcy J.M. Cain)

In article <[e-mail]> [e-mail] writes:
>From:  [e-mail] (Leslie Giles)
>[e-mail] (D'Arcy J.M. Cain) writes:
>>   ... You can
>>also initialise the argument list more than once supporting things such
>>as environment default command lines, arguments from files etc mixed
>>with arguments from the command line.  I just posted it recently to
>>alt.sources and I'm interested in getting some feedback on it.
>
>It is also possible to restart getopt() by setting various variables.
>I did this in some code to support defaults, as mentioned above.  If anybody
>wants to know how to do this then you can mail me (I don't have the code in
>front of me at the moment - it'd take time to find it) at...
>
I guess I wasn't clear in that paragraph.  The posting goes into great detail
about this but the main point is not that you can restart your argument
processing but that another set of arguments can be stuffed into the ones
you already have.  It allows for something like the following:  Say you
have a program called foo which takes options a & b with no arguments and
f with an argument "on" or "off".  Perhaps the user normally wants this flag
off but wants to override that default this time.  Also the a flag is always
used.  The .profile has the following line:

foo="-a -f off"

Assume also that there is a file called bar with the following line:

-b

then he calls the program like this:

foo -f on -@ bar file1 -f off file2

Assuming that the program is set up correctly then the effective command
is

foo -a -f off -f on -b file1 -f off file2

Which should process file1 with the flag turned on and file2 with the flag
turned off.  As you can see, The environment variable is stuffed into the
command line between the program name and the first argument and the contents
of the file bar is inserted in the line where the file name appears.  While
it may be possible to do something like that with getopt I imagine it would
not be as simple as with my interface.

--
D'Arcy J.M. Cain (darcy@druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
[phone]                     |

Note to moderator:  I think this is the wrong group to discuss but I can't
decide the proper one.  Please feel free to add a followup-to line if you
wish.

[ I don't know a better place for it, either. -mod ]

Volume-Number: Volume 20, Number 73

From [e-mail]  Sat Jun 30 15:01:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12874; Sat, 30 Jun 90 15:01:17 -0400
Posted-Date: 30 Jun 90 01:52:12 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA24431; Sat, 30 Jun 90 11:19:35 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13395; Sat, 30 Jun 90 10:34:06 cdt
From: John F. Haugh II <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UIDs and GIDs
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Date: 30 Jun 90 01:52:12 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John F. Haugh II)

In article <[e-mail]> From: [e-mail] (Mark Brown)
>How does one handle (or can one handle) certain networking conventions that
>use a "dummy" user ("nobody") and require a user id of -2 ?

The solution in AIX 3.1 was to use whatever the value of (unsigned) -2
happens to be as an unsigned integer string.  It comes out to be some
real long ugly number ...
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]

                                            Proud Pilot of RS/6000 Serial #1472

Volume-Number: Volume 20, Number 74

From [e-mail]  Sat Jun 30 14:58:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11537; Sat, 30 Jun 90 14:58:30 -0400
Posted-Date: 30 Jun 90 06:07:54 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA24440; Sat, 30 Jun 90 11:19:43 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13502; Sat, 30 Jun 90 10:41:55 cdt
From: Robert A. Bruce <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX test suite
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of California, Berkeley
Date: 30 Jun 90 06:07:54 GMT
Apparently-To: [e-mail]

From: [e-mail] (Robert A. Bruce)

I am looking for a POSIX test suite.  I would prefer free
software, but I would like to hear about commercial suites
too.  Thanks for any info.

        [e-mail]


Volume-Number: Volume 20, Number 75

From [e-mail]  Sat Jun 30 15:02:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13586; Sat, 30 Jun 90 15:02:44 -0400
Posted-Date: 30 Jun 90 10:28:58 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA24501; Sat, 30 Jun 90 11:20:56 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13909; Sat, 30 Jun 90 11:24:08 cdt
From: Richard A. O'Keefe <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Comp Sci, RMIT, Melbourne, Australia
Date: 30 Jun 90 10:28:58 GMT
Apparently-To: [e-mail]

Moderator!:  Delete most of these lines (begin):
Return-Path: <uunet!goanna.cs.rmit.OZ.AU!ok>
Submitted-From: uunet!goanna.cs.rmit.OZ.AU!ok (Richard A. O'Keefe)
Moderator!:  Delete most of these lines (end).

From:  [e-mail] (Richard A. O'Keefe)


>In <[e-mail]> From: [e-mail], Paul Rabin <[e-mail]>
> reports on the April 23-27 meeting in Salt Lake City, UT:
>...
> There was a discussion about whether it is possible (and preferable)
> to improve the low-level directory interfaces instead of adding new,
> high-level interfaces.  Do the high-level interfaces really add new
> functionality for portable applications?  Do they belong with the
> low-level operating system interfaces specified in 1003.1?

In article <[e-mail]>, [e-mail] (Doug Gwyn) writes:
> From:  Doug Gwyn <[e-mail]>
> No, definitely not.  However, they would be appropriate at the 1003.2
> level.

If I want file tree walking, what's wrong with something on the order of
    FILE *files_selected = popen("find ......");
Presumably popen() and 'find' have to be in 1003.2 anyway.  There is
precisely one reason why I can't use this right now, and that is that
'find' doesn't quote its output, so if there is a file name with an
embedded \n things break.  That might be addressed by any number of
methods; one simple method would be to add a
    -length
subcommand which would do the equivalent of
    printf("%d %s\n", strlen(pathname), pathname);
where the existing
    -print
subcommand does the equivalent of
    printf("%s\n", pathname);

If I understand Doug Gwyn correctly, that's the kind of thing he has
in mind.  It is, after all, no more than the traditional UNIX Way.

By the way, I don't quite understand the file tree walking problem.
Unless one has some absolutely compelling reason for requiring a
depth-first search and not using /tmp files, something like 'find'
can be done using
    - one file descriptor to send file names to
      (used sequentially)
    - one file descriptor for a work file
      (random access)
    - one directory descriptor or whatever
      (each directory being opened once, scanned once, and
       never looked at again)
Basically you do a breadth-first search of directories, using the work
file to hold the queue.  If you want some other order, sort the output.
This is, of course, vulnerable to directories being renamed while the
walk is in progress, but so is a depth-first walker that can't hang on
to all the directories in the current branch.

--
"private morality" is an oxymoron, like "peaceful war".

Volume-Number: Volume 20, Number 76

From [e-mail]  Sun Jul  1 12:09:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10223; Sun, 1 Jul 90 12:09:41 -0400
Posted-Date: 1 Jul 90 06:38:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA17519; Sun, 1 Jul 90 11:09:38 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16129; Sun, 1 Jul 90 11:18:40 cdt
From: Barry Margolin <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Date: 1 Jul 90 06:38:34 GMT
Apparently-To: [e-mail]

Moderator!:  Delete most of these lines (begin):
Return-Path: <[e-mail]>
Sender: uunet!Think.COM!news
Submitted-From: uunet!Think.COM!barmar (Barry Margolin)
Moderator!:  Delete most of these lines (end).

From:  [e-mail] (Barry Margolin)

In article <[e-mail]> From: <[e-mail]>
>  The problem being addressed is how to move all printable
>strings out of our programs and into external ``message'' files so
>that we can change program output from, say, English to German by
>changing an environmental variable.

Both examples you supplied were simply ways to look up strings to output in
a database keyed on locale and an internal program string; they differ only
in minor ways.  Does either proposal address any of the *hard* issues?  For
instance, different languages have different pluralization rules; how do
you internationalize a program that automatically pluralizes when necessary
(I hate programs that say things like "1 files deleted")?  Or what about
differing word order; how would you internationalize

    printf("the %s %s", adjective, noun);

so that it would look right in a language where adjectives follow nouns?
--
Barry Margolin, Thinking Machines Corp.

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

Volume-Number: Volume 20, Number 77

From [e-mail]  Sun Jul  1 14:06:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02669; Sun, 1 Jul 90 14:06:44 -0400
Posted-Date: 1 Jul 90 17:48:10 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22578; Sun, 1 Jul 90 13:06:40 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16752; Sun, 1 Jul 90 12:48:41 cdt
From: Mike Schultz <sybil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Original-Date: Sun Jun 17 09:45:41 1990
Date: 1 Jul 90 17:48:10 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Mike Schultz)

[ I thought I posted this one a couple weeks ago, but apparently I
missed it while I was at USENIX.  Sorry about that.  -mod ]

> From:  [e-mail] (Chuck.Phillips)
>
> It *seems* to me that directly implementing mmap() with SVr4 semantics
> under VMS, AGEIS (and of course Multics :-) would be possible.  UNIX
> appears to be the late comer with shared memory.  Am I missing something?

Yes, imbedded controllers that may not have a real file system.

> Regarding IPC and mmap():
>
> If I understand the SVr4 implementation of mmap() correctly, it is only
> possible to share write enabled memory between processes if mmap()ing a
> file system file, but not possible using "anonymous" (a.k.a. swap) memory.
> Is it possible, and if it is possible, are you restricted to sharing
> anonymous memory between parent and child processes due to lack of a
> file system handle?

I'm afraid that I don't understand your question here.  It is .4's specific
goal to not restrict which processes have access to the shared memory.

> In any case, is (or are there plans for) one of the POSIX groups to address
> mmap() (or whatever it will be called) specificly as a method of IPC?  It
> appears SVr4 shared memory (shmat(), et al) offers little mmap() does not
> (or couldn't easily be added, like handles).

I don't know.

Mike Schultz
sybil![e-mail]

Volume-Number: Volume 20, Number 78

From [e-mail]  Sun Jul  1 14:06:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02685; Sun, 1 Jul 90 14:06:53 -0400
Posted-Date: 17 Jun 90 22:15:11 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22603; Sun, 1 Jul 90 13:06:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16819; Sun, 1 Jul 90 12:54:59 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix,comp.std.c
Subject: POSIX and the standard headers
Keywords: POSIX standard C header macro specification
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 17 Jun 90 22:15:11 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

[ Hm.  Another one that got lost off the stack.  I'm rearranging
my mailboxes to avoid this sort of thing.  -mod ]

I've just been informed that the draft IEEE Std 1003.4 (possibly
other POSIX standards-in-progress as well) specifies additional
macros, including EVTCLASS_*, to be defined in <limits.h>.  This
deserves strong condemnation; there is NO EXCUSE for not using
separate headers for the definitions for new facilities.  In
particular, stealing <limits.h> for this purpose forces portable
applications to resort to the
    #define _POSIX_SOURCE    /* or similar "feature test" macro */
    #include <limits.h>
kludge to obtain access to the new definitions, since the C
standard quite properly prohibits the implementation from
defining random stuff in strictly conforming programs.  (Use of
_POSIX_SOURCE provides an escape from strict conformance.)  This
kludgery would not be required for definitions obtained from a
POSIX-specific header, e.g. <async.h> or even <posix4.h>.

The reason for both X3.159 and 1003.1 sharing use of a few of the
standard headers was simply that existing practice (and the base
document for the C library) had already required symbols in them
for both the general-C and UNIX-specific environments.  However,
that was a situation to be accommodated (and for which the special
_POSIX_SOURCE had to be invented, although P1003 didn't do this
the way that X3J11 recommended), not a practice to be actively
encouraged.  Apparently the people drafting the new standards
don't understand why adding stuff to the standard headers is a
bad idea.  To give them something to think about, here is a
practical problem:  Development and installation of the additional
facilities cannot be done, if the standard headers must be modified,
without violating the integrity of a certified standard-conforming
C implementation (and thereby losing certification).

Volume-Number: Volume 20, Number 79

From [e-mail]  Sun Jul  1 14:07:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02710; Sun, 1 Jul 90 14:07:02 -0400
Posted-Date: 25 Jun 90 16:19:07 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22621; Sun, 1 Jul 90 13:06:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16875; Sun, 1 Jul 90 12:57:56 cdt
From: Dorothy Carney <[e-mail]>
Newsgroups: comp.std.unix
Subject: WANTED: Directory Tree Conventions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: earth.lerc.nasa.gov![e-mail]
Organization: NASA Lewis Research Center
Date: 25 Jun 90 16:19:07 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Dorothy Carney)

Our working group is getting started in the use and administration of UNIX
workstations.  Our equipment includes a DECstation, a Sun Sparcstation, a
Data General AViion, and even a Masscomp supermini.  There are many other
computers at our site, including some with flavors of UNIX, for example,
a Cray with Unicos and Amdahl with UTS.  To simplify the administration of
our workstations and to facilitate networking, we are trying to standardize
the directory trees on our workstations.

What conventions have you applied in your UNIX environment?  In particular:
(1) Where do you put user accounts (userids).  (2) Where do you install
third-party software.  (3) Where do you put local utilities.  (4) Do you
create userids for software packages.     Comments & suggestions please!!

Volume-Number: Volume 20, Number 80

From [e-mail]  Sun Jul  1 14:07:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02731; Sun, 1 Jul 90 14:07:10 -0400
Posted-Date: 29 Jun 90 16:42:03 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22631; Sun, 1 Jul 90 13:07:06 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16928; Sun, 1 Jul 90 13:00:01 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UIDs and GIDs
Keywords: versus Networking
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 29 Jun 90 16:42:03 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>How does one handle (or can one handle) certain networking conventions that
>use a "dummy" user ("nobody") and require a user id of -2 ?

One uses, say, 65534 instead.  As of when I was last at Sun, that was what
was going to be done for SunOS 4.1, which would have unsigned user and
group IDs for SVID compliance (and BSD compatibility, for that
matter...).

Volume-Number: Volume 20, Number 81

From [e-mail]  Sun Jul  1 23:16:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23099; Sun, 1 Jul 90 23:16:36 -0400
Posted-Date: 2 Jul 90 00:18:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15083; Sun, 1 Jul 90 22:16:33 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18680; Sun, 1 Jul 90 22:30:49 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 2 Jul 90 00:18:32 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From: [e-mail] (Doug Gwyn)
> The ANSI magtape format is simply inappropriate.  UNIX archives were
> designed to be single files, making it simple to transport them by
> means other than magnetic tape.  In this modern networked world, for
> the most part magnetic tape is an anachronism.  Any archive format
> standard for UNIX should not depend on the archive supporting
> multiple files, tape marks, or any other non-UNIX concept.

I disagree. There are just too many organisations using ANSI format magtapes.
Tar and CPIO should both be retained, but the ability to read and write
standard ANSI magtapes... if the hardware is available... should be part
of a portable operating system standard. So for that matter should such things
as different receive and transmit baud rates (ever hear of V.23 modems?),
but that's another point.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 82

From [e-mail]  Sun Jul  1 23:16:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23115; Sun, 1 Jul 90 23:16:44 -0400
Posted-Date: 2 Jul 90 00:14:19 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15089; Sun, 1 Jul 90 22:16:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18740; Sun, 1 Jul 90 22:33:09 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Mandatory Access Controls in the commercial world
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 2 Jul 90 00:14:19 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

Seems to me that a strict hierarchy is insufficient. What do you do if you
have two sub-organisations for which you don't want to allow *either* to be
able to give files to one another (say, two different marketing groups
setting up separate sealed bids)?
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 83

From [e-mail]  Mon Jul  2 09:44:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25480; Mon, 2 Jul 90 09:44:27 -0400
Posted-Date: 2 Jul 90 07:01:49 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05110; Mon, 2 Jul 90 08:44:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19939; Mon, 2 Jul 90 08:32:11 cdt
From: Phil Ronzone <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: 2 Jul 90 07:01:49 GMT
Apparently-To: [e-mail]

From: [e-mail] (Phil Ronzone)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>You mean, "will include DoD-style security mechanisms". The somewhat
>simple-minded approach UNIX has had in the past has been remarkably
>successful, considering.

I'm not sure what the "DoD-style" words mean, but UNIX has been very deficient
for much serious commercial work due to the "simple-minded" approach it has
had.



>> I like this.  Do you?
>
>Only if it's possible to turn everything off and go back to /etc/passwd
>and /etc/shadow, and a superuser. That way when something goes wrong you'll
>be able to boot from tape or floppy, edit a couple of files, and recover
>the system.
>
>Because something *will* go wrong.

I don't see what this has to do with security.
--
<---------------------------------------------------------------------------->
Philip K. Ronzone                  S e c u r e   U N I X           [e-mail]
Silicon Graphics, Inc. MS 9U-500                           work [phone]
2011 N. Shoreline Blvd., Mountain View, CA 94039            fax [phone]

Volume-Number: Volume 20, Number 84

From [e-mail]  Mon Jul  2 13:01:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14730; Mon, 2 Jul 90 13:01:47 -0400
Posted-Date: 2 Jul 90 15:27:15 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21614; Mon, 2 Jul 90 12:01:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20630; Mon, 2 Jul 90 11:53:36 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 2 Jul 90 15:27:15 GMT
Apparently-To: [e-mail]

From:  Jason Zions <[e-mail]>

Regarding the Snitch Editor's fine report, in the section discussing
1003.12 comes the following sentence:

> Our snitch, Andy Nicholson, challenged readers to find a reason not to
> make DNI endpoints POSIX file descriptors, but has seen no takers.

How about because it constrains implementations to make DNI
kernel-resident?

How about because the semantics of operations permitted on POSIX file
descriptors are a poor match for many transport providers? Read()/write()
are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
maps much more closely to stdio and fgets()/fputs() in that it is
record-oriented. What does it mean to seek() on a network endpoint?

A significant branch of the UNIX(tm)-system and POSIX research community
believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks
are among the leaders here. I feel only slightly squeemish about accusing
them of having only a hammer in their toolbelt; of *course* everything
looks like a nail!

I think it would probably be acceptable to have a DNI function which
accepted a DNI endpoint as argument and attempted to return a real file
descriptor. This function would check to see that the underlying transport
provider could present reasonable semantics through a POSIX file
descriptor, and would also check that the implementation supported access
to that transport provider through a kernel interface.

Jason Zions

*  UNIX is a trademark of AT&T in the US and other countries.
** Obstreperous iconoclast is a behavioral trademark of Jason Zions in the
   US and other countries.

Volume-Number: Volume 20, Number 85

From [e-mail]  Mon Jul  2 18:02:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05412; Mon, 2 Jul 90 18:02:05 -0400
Posted-Date: 2 Jul 90 20:24:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA16596; Mon, 2 Jul 90 17:02:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21729; Mon, 2 Jul 90 16:57:57 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 2 Jul 90 20:24:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>Both examples you supplied were simply ways to look up strings to output in
>a database keyed on locale and an internal program string; they differ only
>in minor ways.  Does either proposal address any of the *hard* issues?  For
>instance, different languages have different pluralization rules; how do
>you internationalize a program that automatically pluralizes when necessary
>(I hate programs that say things like "1 files deleted")?  Or what about
>differing word order; how would you internationalize
>
>    printf("the %s %s", adjective, noun);
>
>so that it would look right in a language where adjectives follow nouns?

The latter can addressed by a scheme like the X/Open NLS scheme, in
which "printf" arguments can be decorated by specifiers that say which
of the N arguments to "*printf" following the format string should be
used; the "the %s %s" would have to replace "%s %s" with "%$2s %$1s".

HOWEVER:

This does *NOT* do anything about the pluralization rules.  It *also*
does nothing about the fact that the correct translation of "the" could
depend on the noun in question; i.e., is it "la" or "le" in French?

I think that, for reasons such as these, the only solution to the
problem of trying to find a Magic Bullet so that you can trivially
internationalize the message-printing code of applications by throwing a
simple-minded wrapper around "printf" (whether the #define approach, or
replacing the format string with "getmsg(the format string)", or
whatever) is to have software that is sufficiently knowledgable about
*all* human languages supported that it knows the gender of all nouns
you'll use in your messages, and knows the right articles for those
genders (for all cases the language has), and knows how to pluralize
arbitrary words.

In fact, I'm not even sure *that's* sufficient; I only know about some
Indo-European languages, and other languages may throw in problems I
haven't even considered.

In other words, I don't think there's a solution to the problem of "oh
dear, how are we going to get all our applications modified to put out
grammatically-correct messages in different languages without having to
examine all the code that generates messages and possibly rewrite some
of that code" other than teaching the system a fair bit about lots of
human languages.  I don't think you can even come up with an approach
that's close enough to a solution to be interesting.  I'm afraid you're
just going to have to fall back on things such as:

    having "1 frob" and "%d frobs" be *two* separate messages in the
    message catalog;

    having "the chair" and "the table" either be two separate
    messages, rather than having "the %s" and foreign-language
    versions of same, or having the message be "%s %s" and have the
    database tie the noun and the article together (watch out for
    Russian, though, they don't *use* articles...);

etc..

Yeah, this may mean human intervention, rather than being able to
internationalize your messages by running just running a few programs
over the code; nobody ever said that life was fair.  Might as well bite
the bullet....

Volume-Number: Volume 20, Number 86

From [e-mail]  Tue Jul  3 12:04:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10298; Tue, 3 Jul 90 12:04:06 -0400
Posted-Date: 3 Jul 90 02:57:47 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01765; Tue, 3 Jul 90 11:04:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23163; Tue, 3 Jul 90 10:53:35 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 3 Jul 90 02:57:47 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
-In article <[e-mail]> From: [e-mail] (Doug Gwyn)
-> The ANSI magtape format is simply inappropriate.  UNIX archives were
-> designed to be single files, making it simple to transport them by
-> means other than magnetic tape.  In this modern networked world, for
-> the most part magnetic tape is an anachronism.  Any archive format
-> standard for UNIX should not depend on the archive supporting
-> multiple files, tape marks, or any other non-UNIX concept.
-I disagree. There are just too many organisations using ANSI format magtapes.
-Tar and CPIO should both be retained, but the ability to read and write
-standard ANSI magtapes... if the hardware is available... should be part
-of a portable operating system standard.

We're apparently not talking about the same thing.  I was talking about
the POSIX standard for archiving collections of files.  There is no
particular reason why that should require use of magnetic tape.  I'm not
proposing that ANSI (or ISO) magtape standards not be followed where
appropriate; you could for example put a tar or cpio archive within a
file on an ANSI-labeled magtape.  However, you can also put a tar or cpio
archive within a file on a disk, and you can ship it across a network as
a single entity, something that is not possible for ANSI magtapes in
general.

Volume-Number: Volume 20, Number 87

From [e-mail]  Tue Jul  3 12:04:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10373; Tue, 3 Jul 90 12:04:29 -0400
Posted-Date: 3 Jul 90 04:44:27 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01829; Tue, 3 Jul 90 11:04:25 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23231; Tue, 3 Jul 90 10:56:54 cdt
From: Eric Schnoebelen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Summary: ANSI tape, tar, cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Central Iowa (Model) Railroad, Dallas, Tx.
Date: 3 Jul 90 04:44:27 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Eric Schnoebelen)

In article <[e-mail]> Peter da Silva writes:
- In article <[e-mail]> From: [e-mail] (Doug Gwyn)
- > The ANSI magtape format is simply inappropriate.  UNIX archives were
- > designed to be single files, making it simple to transport them by
- > means other than magnetic tape.
-
- I disagree. There are just too many organisations using ANSI format magtapes.
- Tar and CPIO should both be retained, but the ability to read and write
- standard ANSI magtapes... if the hardware is available... should be part
- of a portable operating system standard.

        ANSI tape can be supported via a set of programs over the
standard Unix system (ConvexOS 8.0 and above do so, along with many
other "mainframe" tape subsystem features) but ANSI labeled tapes are
inappropriate for file archival.  With a properly designed ANSI tape
subsystem, it is easy enough to have tar, and cpio (and even
dump/restore) use ANSI labeled tapes, and it can be totally transparent
to the user.

        Thus, we have the POSIX standard archive on the ANSI standard
magnetic tape format..

--
Eric Schnoebelen        [e-mail]        [e-mail]
    Churchill's Commentary on Man: Man will occasionally stumble over the
    truth, but most of the time he will pick himself up and continue on.

Volume-Number: Volume 20, Number 88

From [e-mail]  Tue Jul  3 16:57:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16094; Tue, 3 Jul 90 16:57:30 -0400
Posted-Date: 3 Jul 90 18:18:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25640; Tue, 3 Jul 90 15:53:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23963; Tue, 3 Jul 90 15:32:22 cdt
From: david paul hoyt <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jul 90 18:18:00 GMT
Apparently-To: [e-mail]

From:  david paul hoyt <[e-mail]>

>                                   With a properly designed ANSI tape
> subsystem, it is easy enough to have tar, and cpio (and even
> dump/restore) use ANSI labeled tapes, and it can be totally transparent
> to the user.

  And better yet, we'll have a standard way of dealing with multi-volumne
tapes.  It's hard enough to backup your own multi-gigabyte disk system, let
alone send large databases to other (potentially non-unix) systems.

david | [e-mail] | dhoyt@umnacvx

Volume-Number: Volume 20, Number 89

From [e-mail]  Wed Jul  4 00:20:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03827; Wed, 4 Jul 90 00:20:46 -0400
Posted-Date: 3 Jul 90 20:41:28 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21914; Tue, 3 Jul 90 23:20:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24803; Tue, 3 Jul 90 23:03:26 cdt
From: Kee Hinckley <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities [NLS stuff]
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: asi
Date: 3 Jul 90 20:41:28 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Kee Hinckley)

In article <[e-mail]> From: <[e-mail]>
>To help you think about the problem, here's the way you'll have to
>write the "hello, world" koan using the X/OPEN interfaces:
....
>          (void)setlocale(LC_ALL, "");
>          catd = catopen("hello", 0); /* error checking omitted for brevity */
>          printf(catgets(catd, 1, 1,"hello, world\n"));
....
>and using the alternative, proposed UniForum interfaces:
....
>          (void)setlocale(LC_ALL, "");
>          (void)textdomain("hello");
>          printf(gettext("hello, world\n"));
....
>I suppose if I had my druthers, I'd like to see a standard interface
>that goes even farther than the UniForum proposal: one that adds a
....
>          (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
>          printf("hello, world\n");
....
>but that would still be untested innovation.

First of all, I don't think that either of these add enough of value to the
X/Open standard to make it worthwhile for those of using it to switch.
The use of strings as an index into the catalog though is definitely a BAD IDA.

Why?  A number of reasons.  First of all it's ethnocentric.  You've just told
every Easterner/MiddleEasterner that the default language is English.  Secondly
it's inefficent to and a pain to implement.  Thirdly it can produce results
which are just plain wrong.  I have different places in my application where
the English string is currently the same.  Using these schemes it would always
look up the same item in the catalog.  However in a different language the
string might well be different, but there would be no way of changing it one place
and not the other.

BTW.  Where can I get a specification of the Uniforum proposal (and comment
on it)?

The complexity of the X/Open stuff is easily hidden on a per application basis.
Anytime I want to reference a string in my application all I have to say
is MC(foo), where foo is #defined appropriately.

Where I *do* see room for improvement is in the definition of the catalog
file itself.  There is currently no specification for generating include
files or anything else, and hand numbering the strings is a royal pain.

If you consider the X/Open form:

$set 1 OmUA
$ #To
1 To:
$ #From
2 From:
$ #Subject
3 Subject:

(where '$ ' is a comment).  I've written a parser that
treats comments beginning with '#' as special and allows
'#' instead of the number.  Thus

$set 1 OmUA
$ #To
# To:
$ #From
# From:
$ #Subject
# Subject:

generates

#ifndef __msgsH
#define __msgsH

#define SETOmUA    1
#define OmUATo    1
#define OmUAFrom    2
#define OmUASubject    3

#endif

It would be nice to be able to rely on this kind of functionality.

--
Alphalpha Software, Inc.    |    [e-mail]
[e-mail]        |-----------------------------------
617/646-7703 (voice/fax)    |    Proline BBS: 617/641-3722

I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

Volume-Number: Volume 20, Number 90

From [e-mail]  Wed Jul  4 00:20:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03843; Wed, 4 Jul 90 00:20:56 -0400
Posted-Date: 3 Jul 90 22:37:23 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21920; Tue, 3 Jul 90 23:20:54 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24870; Tue, 3 Jul 90 23:06:45 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jul 90 22:37:23 GMT
Apparently-To: [e-mail]

From:  [e-mail]

>From:  [e-mail] (peter da silva)
>I disagree. There are just too many organisations using ANSI format magtapes.
>Tar and CPIO should both be retained, but the ability to read and write
>standard ANSI magtapes... if the hardware is available... should be part...

Uh, Peter, go back and look at what Doug wrote.  He never said anything,
either positive or negative, about the ability to use ANSI magtapes.  The
point is that the ANSI magtape format assumes a storage medium which has
notions like block boundaries and tape marks, and it is grossly mismatched
to the requirement for a Unix archiving format.

>...So for that matter should such things
>as different receive and transmit baud rates (ever hear of V.23 modems?),
>but that's another point.

Peter, would it be too much to ask whether you have *read* the standards
you are criticizing?  1003.1 supports split baud rates.

                                         Henry Spencer at U of Toronto Zoology
                                          [e-mail]   utzoo!henry

Volume-Number: Volume 20, Number 91

From [e-mail]  Wed Jul  4 00:21:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03957; Wed, 4 Jul 90 00:21:06 -0400
Posted-Date: 3 Jul 90 21:07:30 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21932; Tue, 3 Jul 90 23:21:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24926; Tue, 3 Jul 90 23:08:43 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 3 Jul 90 21:07:30 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

>From:  [e-mail] (Guy Harris)
>In other words, I don't think there's a solution to the problem of "oh
>dear, how are we going to get all our applications modified to put out
>grammatically-correct messages in different languages without having to
>examine all the code that generates messages and possibly rewrite some
>of that code" other than teaching the system a fair bit about lots of
>human languages.

Might as well leave out the clause "other than ...".

Perhaps we could persuade those who think there should be a simple rule
for writing just one message text when programming for a variety of
cultures to use Esperanto for their messages.  At least that way they
will be understood just as readily by all customers..  :-)

Volume-Number: Volume 20, Number 92

From [e-mail]  Wed Jul  4 00:21:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04324; Wed, 4 Jul 90 00:21:54 -0400
Posted-Date: 3 Jul 90 22:43:54 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21949; Tue, 3 Jul 90 23:21:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24994; Tue, 3 Jul 90 23:11:45 cdt
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jul 90 22:43:54 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Henry Spencer)

>From:  Jason Zions <[e-mail]>
>How about because it constrains implementations to make DNI
>kernel-resident?

Nonsense.  Nothing in 1003.n constrains implementations to make anything
kernel-resident.  Things like read() are functions, which may or may not
reflect the primitives of the underlying kernel.  They are merely required
to communicate -- somehow -- with something that performs the required
services.

Why have two different kinds of endpoints for I/O?  We already have one
which is general enough to encompass almost every kind of I/O under the sun.

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented. What does it mean to seek() on a network endpoint?

Read()/write() are stream operations that work perfectly well as record
operations too.  As witness Unix ttys, which are record-oriented devices
on input, and Unix magtapes, which are record-oriented both ways.  As for
what it means to seek on a network endpoint, exactly the same as it means
to seek on a tty:  probably nothing.  But why invent new mechanisms for
I/O when the old ones will do perfectly well?

"Don't fix it if it ain't broken."

                                         Henry Spencer at U of Toronto Zoology
                                          [e-mail]   utzoo!henry

Volume-Number: Volume 20, Number 93

From [e-mail]  Wed Jul  4 00:22:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04393; Wed, 4 Jul 90 00:22:02 -0400
Posted-Date: 3 Jul 90 18:19:11 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21955; Tue, 3 Jul 90 23:21:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA25056; Tue, 3 Jul 90 23:15:20 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 3 Jul 90 18:19:11 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From: [e-mail] (Jason Zions)
> Read()/write() are stream operations; only TCP is a stream transport
> provider. OSI TP0/2/4 maps much more closely to stdio and fgets()/fputs()
> in that it is record-oriented.

The same is true of a UNIX tty device with canonical processing. So?

> What does it mean to seek() on a network endpoint?

What does it mean to seek() on a pipe?
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 94

From [e-mail]  Wed Jul  4 00:22:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04460; Wed, 4 Jul 90 00:22:09 -0400
Posted-Date: 3 Jul 90 18:16:09 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21970; Tue, 3 Jul 90 23:22:06 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA25115; Tue, 3 Jul 90 23:18:20 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 3 Jul 90 18:16:09 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From: [e-mail] (Phil Ronzone)
> I'm not sure what the "DoD-style" words mean, but UNIX has been very deficient
> for much serious commercial work due to the "simple-minded" approach it has
> had.

This may well be true. But for a large set of problems the existing UNIX
security approach is quite sufficient. If you don't have the actual hardware
secured it's overkill.

> >Only if it's possible to turn everything off and go back to /etc/passwd
> >and /etc/shadow, and a superuser. That way when something goes wrong you'll
> >be able to boot from tape or floppy, edit a couple of files, and recover
> >the system.

> >Because something *will* go wrong.

> I don't see what this has to do with security.

I know of at least one case where a hard error in the user database for
a system required sending a letter from the president of the user's
company to the vendor to get them to explain how to regain access to the
system. Security and convenience are opposed goals, and sometimes a system
MUST be available.

If *all* POSIX conformant systems come with a stronger security system than
UNIX installed, it must be possible to set things up so that security system
can be defeated and a new system set up with physical access to the hardware.
It's acceptable for there to be some magic one-way juju that you can do to
put the system into a highly secure state, but it should not come that way.
I will neither purchase nor recommend any system I can't get into and rebuild
the access system with a boot floppy and the console.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 95

From [e-mail]  Wed Jul  4 12:27:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10176; Wed, 4 Jul 90 12:27:27 -0400
Posted-Date: 4 Jul 90 08:55:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA13158; Wed, 4 Jul 90 11:27:23 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00290; Mon, 4 Jun 90 11:19:24 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tsa.co.uk![e-mail]
Organization: The Standard Answer Ltd.
Date: 4 Jul 90 08:55:34 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

In article <[e-mail]> [e-mail] (Doug Gwyn) fulminates
> The ANSI magtape format is simply inappropriate.  UNIX archives were
> designed to be single files, making it simple to transport them by
> means other than magnetic tape.  In this modern networked world, for
> the most part magnetic tape is an anachronism.  Any archive format
> standard for UNIX should not depend on the archive supporting
> multiple files, tape marks, or any other non-UNIX concept.

Er.  As Jason Zions points out in <[e-mail]>,
> A significant branch of the UNIX(tm)-system and POSIX research community
> believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks
> are among the leaders here. I feel only slightly squeamish about accusing
> them of having only a hammer in their toolbelt; of *course* everything
> looks like a nail!

The network as a featureless data stream is another example of the same
``traditional'' thinking in the UNIX community.  Actually, the
datagram-based schemes favoured in the US (oversimplifying grossly, we
Europeans have a preference for connection-based systems which do deliver
streams) can provide nice record boundaries, which could in turn be used to
delimit labels for the proposed tape archive format (after adding some
reliability and sequencing).  Just because the format is based on IS 1003
for labelled magnetic tapes does not mean to say that it cannot be used on
other media, networks among tham.  After all, tar's a format for blocked
magnetic tapes, but that hasn't stopped us moving tar archives over
networks.
--
Dominic Dunlop

Volume-Number: Volume 20, Number 96

From [e-mail]  Wed Jul  4 13:57:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18668; Wed, 4 Jul 90 13:57:59 -0400
Posted-Date: 3 Jul 90 18:12:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA16493; Wed, 4 Jul 90 12:57:54 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00816; Wed, 4 Jul 90 12:43:42 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 3 Jul 90 18:12:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented.

Standard I/O, and "fgets()"/"fputs()" in particular, are
record-oriented?  News to me; I thought standard I/O offered byte
streams, and "fgets()" read stuff from that stream until it hit a
newline or EOF, and "fputs" put bytes from a string out onto that
stream.

For that matter, raw magtapes are also record oriented, and "read()" and
"write()" work fine on them.  I don't see the problem with TPn; a single
"write()" could either be turned into one packet, or broken up
arbitrarily into N packets if there's a maximum packet size.  If you
*want* to have a correspondence between "send it" calls and records, I
see no problem with providing additional calls to do that, but I also
don't see any problem with hiding record boundaries, if necessary, from
applications that *want* to just send byte streams over TPn.

>What does it mean to seek() on a network endpoint?

What does it mean to "seek()" on a tty?

Volume-Number: Volume 20, Number 96

From [e-mail]  Thu Jul  5 17:50:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29638; Thu, 5 Jul 90 17:50:49 -0400
Posted-Date: 5 Jul 90 03:40:11 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07699; Thu, 5 Jul 90 16:50:46 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04772; Thu, 5 Jul 90 16:01:15 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 5 Jul 90 03:40:11 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> uunet!tsa.co.uk![e-mail] writes:
>After all, tar's a format for blocked magnetic tapes, ...

No, it is not.  A "tar" archive is merely a stream of bytes, all of
whose structure is contained internally.  The designers of "tar" and
(to a lesser extent) "cpio" archive formats did, however, take into
account the blocked nature of such media, so that it would be
convenient to use such media to hold the archive.  This was entirely
appropriate and does not require that such media be used.

Volume-Number: Volume 20, Number 97

From [e-mail]  Thu Jul  5 17:50:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29670; Thu, 5 Jul 90 17:50:56 -0400
Posted-Date: 5 Jul 90 13:26:58 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07707; Thu, 5 Jul 90 16:50:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04827; Thu, 5 Jul 90 16:03:13 cdt
From: Karl Heuer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 5 Jul 90 13:26:58 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Karl Heuer)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>As for what it means to seek on a network endpoint, exactly the same as it
>means to seek on a tty: probably nothing.

Better yet, it should return an error (like an attempt to seek on a pipe).  I
don't think there's any excuse for tty seek having been defined as a no-op in
the first place; it's too bad POSIX didn't require this to be fixed.  (Is
there any reliable way to tell whether a given fd is seekable?)

Volume-Number: Volume 20, Number 98

From [e-mail]  Thu Jul  5 17:51:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29697; Thu, 5 Jul 90 17:51:04 -0400
Posted-Date: 4 Jul 90 11:57:02 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07720; Thu, 5 Jul 90 16:51:02 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04885; Thu, 5 Jul 90 16:05:15 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 4 Jul 90 11:57:02 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] writes:
> Uh, Peter, go back and look at what Doug wrote....

> Peter, would it be too much to ask whether you have *read* the standards
> you are criticizing? ...

Um, yes. I do seem to have written that with my brain disengaged. Apologies
all round.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 99

From [e-mail]  Thu Jul  5 20:29:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12636; Thu, 5 Jul 90 20:29:55 -0400
Posted-Date: 5 Jul 90 19:25:49 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19602; Thu, 5 Jul 90 19:29:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05317; Thu, 5 Jul 90 18:48:27 cdt
From: Phil Ronzone <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: 5 Jul 90 19:25:49 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Phil Ronzone)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>This may well be true. But for a large set of problems the existing UNIX
>security approach is quite sufficient. If you don't have the actual hardware
>secured it's overkill.

I disagree - secure software, from the boot code on, is very effective.

>Security and convenience are opposed goals, and sometimes a system
>MUST be available.

I disagree again -- I think the recent Internet worm is an example of why.

--
<---------------------------------------------------------------------------->
Philip K. Ronzone                  S e c u r e   U N I X           [e-mail]
Silicon Graphics, Inc. MS 9U-500                           work [phone]
2011 N. Shoreline Blvd., Mountain View, CA 94039            fax [phone]





Volume-Number: Volume 20, Number 100

From [e-mail]  Thu Jul  5 20:32:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13819; Thu, 5 Jul 90 20:32:28 -0400
Posted-Date: 5 Jul 90 21:24:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19756; Thu, 5 Jul 90 19:32:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05492; Thu, 5 Jul 90 19:18:46 cdt
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: correction (compression algorithm patents)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Jul 90 21:24:17 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Jeffrey S. Haemer)

Five people have now brought to my attention that my
recent editorial says the compress/uncompress algorithm is
copyrighted: Dave Grindelman, Guy Harris, Keith Bostic, Randall
Howard, and Hugh Redelmeier.  That's wrong.  It isn't
copyrighted, it's patented.  My apologies to anyone I mislead.

Randall's note contains a lot of interesting details that it's worth posting
and he's given me permission to post it.
I've appended it.

Jeff

=====
[From Randall Howard]

    Actually the problem is not that the compress algorithm is copyrighted
but that it is PATENTED by Welch (the "W" in the LZW name of the algorithm).
The patent is currently held by Unisys Corporation and they make money
from licence fees on that patent because of the use of LZW encoding
in the new high-speed modems.  Note that the Lempel-Ziv algorithm
is apparently not patented, but just the Welch variant as is found in the
UNIX compress utility.  Therefore, at the cost of inventing a new file
compression standard, it would be possible to escape licence fees by
using a different variant of LZ compression.

    [Editor: Keith Bostic says both are patented:
    original Ziv-Lempel is patent number 4,464,650,
    and the more powerful LZW method is #4,558,302.
    He goes on to say, however, that LZW lacks adaptive table reset
    and other features in compress, and so may not apply.]

    The implications of this are that no one may produce the same
output as compress produces, regardless of the program that produced
that output, without being subject to the patent.  I.e., it is independent
of the actually coding used, unlike copyright.  Therefore, all of the PD
versions of compress are currently in violation, as is BSD.

    Representatives of Unisys at the POSIX.2 meetings claimed that
the Unisys Legal Department is pursuing the licensing of compress.  In fact,
unlike copyright or trade secret protection, patent protection does not
diminish because the holder of the patent is not diligent in seeking damages
or preventing unauthorized use.  Witness the large royalty payout by
Japanese semiconductor companies to Texas Instruments because they held
the patent on the concept of something as fundamental as integrated circuits.
This licence payout spans a period of over 20 years.  In addition,
Unisys representatives claim that Phil Karn's PKZIP, which uses the
LZW compression algorithm, is a licenced user of the Unisys patent and
that a fee (rumoured to be somewhere in the $10,000 to $20,000 US range)
has been paid up front in lieu of individual royalties.

    The ramifications for POSIX.2a are unclear.  Currently, there are members
of the working group that say that they would object if a patented
algorithm were required by the standard if ANY FEE WHATSOEVER (even if $1)
were required to use it.  (There are, however, precedents for standards
working in areas of patents in such areas as networking, modems, and
hardware bus structures.  It appears that we software people have not
"grown up" as much when it comes to issues of licensing.  Who has ever
hear of "public domain hardware"?)  Some people suggested that Unisys
should allow relatively free use of the patent but should profit from
publicity rights from a citation in every POSIX.2a product manual that
contains compress.  Therefore, there are currently negotiations underway
to see what kind of "special deal" Unisys would be willing to cut for the
use strictly in implementations of POSIX.2a.  Depending on the outcome
of these negotiations, compress would either be dropped, re-engineered,
or retained.

Volume-Number: Volume 20, Number 101

From [e-mail]  Thu Jul  5 23:55:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02466; Thu, 5 Jul 90 23:55:56 -0400
Posted-Date: 5 Jul 90 23:51:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA29210; Thu, 5 Jul 90 22:55:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06027; Thu, 5 Jul 90 22:57:39 cdt
From: James Buster <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Mandatory Access Controls in the commercial world
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Vicom Systems, Inc.
Date: 5 Jul 90 23:51:34 GMT
Apparently-To: [e-mail]

From:  [e-mail] (James Buster)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>Seems to me that a strict hierarchy is insufficient. What do you do if you
>have two sub-organisations for which you don't want to allow *either* to be
>able to give files to one another (say, two different marketing groups
>setting up separate sealed bids)?

    First, a short overview of MAC:

A MAC (Mandatory Access Control) label has *two* components, a hierarchical
_level_ and a non-hierarchical _set of categories_.

Label A is said to _dominate_ label B if the hierarchical _level_ of label
A >= the level of label B *and* the _set of categories_ of label A is a
(possibly improper) superset of B's _categories_. The '>=' relationship
denotes an ordering that is not necessarily based on the integers or
natural numbers, but is intended to imply superiority or supremacy.

For a _subject_ (e.g. a UNIX process) with label A to *read* from an object
with label B, A must _dominate_ B. For a subject with label A to *write* to
an object with label B, B must _dominate_ A. This implies that to both *read*
and *write* to an object, A must equal B. An object is created with the label
of the subject that creates it. Some security policies may have more
restrictive rules.

The upshot of all this is that, for your example, each marketing group
will have a set of categories that is disjoint (e.g. A is in the category
International and B is in Domestic). You can see from the MAC read rule above
that this ensures there will be no information flow from Marketing Group A
to Marketing Group B.
--
---------------------------------------------------------------------
        James Buster        (Domain) [e-mail]
  Mad Hacker Extraordinaire    (UUCP)   ...!ames!vsi1!bitbug
---------------------------------------------------------------------

Volume-Number: Volume 20, Number 102

From [e-mail]  Fri Jul  6 11:32:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11974; Fri, 6 Jul 90 11:32:28 -0400
Posted-Date: 5 Jul 90 21:30:45 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA24240; Fri, 6 Jul 90 10:32:25 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA07312; Fri, 6 Jul 90 10:17:03 cdt
From: Mike Urban <[e-mail]>
Newsgroups: comp.std.unix
Subject: Printing Standards?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mike Urban)
Organization: RAND Corp., Santa Monica, Ca.
Date: 5 Jul 90 21:30:45 GMT
Apparently-To: [e-mail]

From: [e-mail] (Mike Urban)

What incipient or existing standards, if any, specify
the Shell-level printer interface (lpr and its friends)?
--

    Mike Urban
    [e-mail]

Volume-Number: Volume 20, Number 103

From [e-mail]  Fri Jul  6 11:34:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12483; Fri, 6 Jul 90 11:34:06 -0400
Posted-Date: 6 Jul 90 06:58:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA24354; Fri, 6 Jul 90 10:34:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA07372; Fri, 6 Jul 90 10:21:05 cdt
From: Steven M. Schultz <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Steven M. Schultz)
Organization: Contel Federal Systems
Date: 6 Jul 90 06:58:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Steven M. Schultz)

In article <[e-mail]> From:  [e-mail] (Phil Ronzone)
>In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>>This may well be true. But for a large set of problems the existing UNIX
>>security approach is quite sufficient. If you don't have the actual hardware
>>secured it's overkill.
>
>I disagree - secure software, from the boot code on, is very effective.

    i have to side with Peter on this.  the keywords were "large set
    of problems" and "quite sufficient" - that doesn't (at least to
    me) obviate the need for more strict security when the need
    arises, but for many situations just administering the systems
    correctly is enough.

    short of soldiers with M16s at a computer facility door i do not
    believe that software is any substitute for physical security.
    it's just one more password that has to be spread around (in
    case the SSO or whoever) goes on vacation, etc...

>>Security and convenience are opposed goals, and sometimes a system
>>MUST be available.

    agreed.

>I disagree again -- I think the recent Internet worm is an example of why.

    now it's my turn to disagree.  sheesh, why does the worm have to
    be brought up everytime security is discussed?  it was a BUG that
    was exploited, and i for one do not think that adding security
    will do away with BUGs in software.  on the contrary, as the
    complexity of the system is increased by the added software the
    number of bugs could actually increase, no?

    and, if people can't administer systems "correctly" now - what's
    going to happen when the amount of administration required increases
    due to the files/databasei/etc that "security" will add to the system??

    Steven M. Schultz
    [e-mail]

Volume-Number: Volume 20, Number 104

From [e-mail]  Fri Jul  6 11:34:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12510; Fri, 6 Jul 90 11:34:17 -0400
Posted-Date: 6 Jul 90 13:53:22 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA24369; Fri, 6 Jul 90 10:34:14 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA07436; Fri, 6 Jul 90 10:24:33 cdt
From: Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX test suite
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The MITRE Corp., Bedford, MA
Date: 6 Jul 90 13:53:22 GMT
Apparently-To: [e-mail]

From: [e-mail] (Cazier)

    It doesn't look like a free POSIX test suite is just yet around the
corner. The (federal) NIST has a POSIX Conformance Test Suite available
but it's not free, and it involves several 1000's of lines of code.

You might call Roger Martin at the NIST at 301-975-3295 to get more details
on the PCTS.

Volume-Number: Volume 20, Number 105

From [e-mail]  Fri Jul  6 11:34:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12548; Fri, 6 Jul 90 11:34:27 -0400
Posted-Date: 6 Jul 90 14:13:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA24409; Fri, 6 Jul 90 10:34:25 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA07497; Fri, 6 Jul 90 10:27:09 cdt
From: Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: portability of tar tapes
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The MITRE Corp., Bedford, MA
Date: 6 Jul 90 14:13:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Cazier)

How portable are tar tapes from one machine to another. My experience
has been that tar within a vendor's site is portable but to try to
carry a tar 1/4" tape from one vendor to another --- that's another story.

The only thing I've had luck with is 1600 bpi reel tapes written in cpio -
which is definitely not friendly to the casual user.

Volume-Number: Volume 20, Number 106

From [e-mail]  Fri Jul  6 20:57:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26783; Fri, 6 Jul 90 20:57:46 -0400
Posted-Date: 6 Jul 90 05:28:35 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05034; Fri, 6 Jul 90 19:57:44 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09098; Fri, 6 Jul 90 19:49:02 cdt
From: Jim Kingdon <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Mandatory Access Controls in the commercial world
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 6 Jul 90 05:28:35 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Jim Kingdon)

Thanks for providing some technical details.  But can't the level be
made a special case of the set of categories?  That is, define
categories CLASSIFIED, SECRET, TOP_SECRET, etc, and give people either
{TOP_SECRET, SECRET, CLASSIFIED} or {SECRET, CLASSIFIED} or
{CLASSIFIED}.  Unless I'm missing something, this provides the same
functionality and is simpler.

You might want to post a clarification (or summary of this and other
messages).

Volume-Number: Volume 20, Number 107

From [e-mail]  Fri Jul  6 20:57:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26863; Fri, 6 Jul 90 20:57:52 -0400
Posted-Date: 6 Jul 90 14:38:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05040; Fri, 6 Jul 90 19:57:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09158; Fri, 6 Jul 90 19:51:42 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 6 Jul 90 14:38:32 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Phil Ronzone) writes:
> In article <[e-mail]> [e-mail] (Peter da Silva) writes:
> >This may well be true. But for a large set of problems the existing UNIX
> >security approach is quite sufficient. If you don't have the actual hardware
> >secured it's overkill.

> I disagree - secure software, from the boot code on, is very effective.

I'm sure it is. An SR71 is very effective, too, but I find a 747 a whole
lot more convenient for a trip to Hawaii.

> >Security and convenience are opposed goals, and sometimes a system
> >MUST be available.

> I disagree again -- I think the recent Internet worm is an example of why.

What do you disagree with? That security and convenience are opposed goals,
or that sometimes a system MUST be available? And why?

(what the internet worm has to do with anything is another question. There
 have been similar incidents on systems with tighter security requirements,
 such as the DECNET WANK incident or the CHRISTMAS TREE virus. For that matter
 I have laid out the preliminary design for a virus that can propogate via
 Usenet source archives. And from what I know of the internet worm it would
 have spread pretty near as fast if sendmail didn't run under root permissions.
 start with a non-sequiter and I guess you can prove anything)
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>


Volume-Number: Volume 20, Number 108

From [e-mail]  Sat Jul  7 10:59:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13763; Sat, 7 Jul 90 10:59:03 -0400
Posted-Date: 6 Jul 90 10:27:31 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00803; Sat, 7 Jul 90 09:58:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA11081; Sat, 7 Jul 90 09:54:23 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: correction (compression algorithm patents)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tsa.co.uk![e-mail]
Organization: The Standard Answer Ltd.
Date: 6 Jul 90 10:27:31 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

>From:  [e-mail] (Jeffrey S. Haemer) quoting Randall Howard
>
>    The ramifications [of the fact that the LZ and LZW compression
>algorithms are patented ] for POSIX.2a are unclear.  Currently, there
>are members of the working group that say that they would object if a
>patented >algorithm were required by the standard if ANY FEE WHATSOEVER
>(even if $1) were required to use it.  (There are, however, precedents
>for standards working in areas of patents in such areas as networking,
>modems, and hardware bus structures.  It appears that we software people
>have not "grown up" as much when it comes to issues of licensing.

For the record, from (normative) Annex A of IEC/ISO Directives -- Part 2:
Methodology, 1989:

   If, in exceptional cases, technical reasons justify the preparation
   of an International Standard in terms which include that use of a
   patented item, there is no objection in principle to such a step,
   even if the terms are such that there is no alternative means of
   compliance.  In such a case, the following procedures shall be
   complied with.

      a)  ISO and IEC cannot give authoritative or comprehensive information
      about evidence, validity and scope of patent and like rights but it
      is desirable that the fullest information be disclosed.  Therefore
      the originator of a proposal of such a kind shall draw the technical
      committee's or subcommittee's attention to any known patent and like
      rights on a worldwide basis or any known pending applications,
      although ISO and IEC are not in a position to guarantee the authority
      of any such information.

      b)  If the proposal is accepted on technical grounds, the originator
      shall ask any known patent holder for a statement that he would be
      willing to negotiate licences under patent and like rights for
      applicants throughout the world on reasonable terms and conditions.
      A record of the patent holder's statement shall be placed in the
      files of the ISO Central Secretariat or the IEC Central Office, as
      appropriate, and shall be referred to in the relevant international
      standard.  If the patent holder does not provide such a statement,
      the technical committee shall not proceed with the inclusion of the
      patented item unless the respective Council gives permission.

      c)  Should it be revealed after publication of the International
      Standard that licences under a patent and like rights cannot be
      obtained under reasonable terms and conditions, the International
      Standard shall be referred back to the technical committee for
      further consideration.

(The Councils of IEC and ISO are defined as ``the ultimate authority for
the technical work...'')

And from section 7, IEEE Standards Manual, April 1988:

   7. Patents

   There is no objection in principle to drafting a proposed IEEE standard
   in terms that include the use of a patented item, if it is considered
   that technical reasons justify this approach.

   7.1 Disclaimer

   The following note shall appear in all IEEE standards:

      ``IEEE standards documents are adopted by the Institute of Electrical
      and Electronic Engineers without regard to whether their adoption may
      involve patents on articles, materials, or processes.  Such adoption
      does not assume any liability to any patent owner, nor does it assume
      any obligation to any parties whatever adopting the standards
      documents.''

(This note duly appears in IEEE Std. 1003.1:1988, facing the title page.)

Think I prefer ISO's cautious but realistic approach to the IEEE's mere
shrugging off of any blame for any consequences whatever of any action it
cares to take.
--
Dominic Dunlop

Volume-Number: Volume 20, Number 109

From [e-mail]  Sat Jul  7 11:06:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15011; Sat, 7 Jul 90 11:06:10 -0400
Posted-Date: 5 Jul 90 13:56:01 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01275; Sat, 7 Jul 90 10:05:55 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA11159; Sat, 7 Jul 90 10:04:33 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Report on ISO POSIX meeting of June 1990
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Jul 90 13:56:01 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

          Report on ISO/IEC JTC1/SC22/WG15 (POSIX)
      Meeting of 11th - 15th June, 1990, Paris, France

             Dominic Dunlop  -- [e-mail]

                  The Standard Answer Ltd.

                        Introduction

Working Group 15 of Subcommittee 22 of Joint Technical
Committee 1 of the International Organization for
Standardization and the International Electrotechnical
Commission (ISO/IEC JTC1/SC22/WG15), or, more briefly, the
ISO POSIX working group, met in Paris, France, from the 12th
to the 15th of June.  The meeting was hosted by AFNOR,
(Association francaise de normalisation), the French
national standards body, at its offices in La Defense, a
high-rise business district a brisk train-ride away from the
city centre, and was preceded on 11th June and the morning
of the 12th by meetings of the rapporteur groups on
conformance testing, internationalization and security.
Attendance was good, with thirty "experts" (as the ISO
Directives style us) representing nine countries, plus the
European Community.

I was present at the main meeting and at the
internationalization rapporteur group as an observer with
the brief of reporting back to you.  This report is the
fourth jointly commissioned by the European UNIX systems
User Group (EUUG) and USENIX.  As usual, it's a little
imprecise in its references to ISO.  Strictly, most of these
should be to JTC1, or to some part of JTC1.  Where precision
is needed, I use it and give an explanation, but for the
most part I refer simply to ISO, so as to avoid getting
bogged down in unnecessary detail.  If you have any
comments, or need clarification or further information,
please contact me at the mail address above.

First, a summary of the most important aspects of the
meeting:

                          Summary

   o POSIX.1, the operating system interface standard,
     should be published as international standard 9945-1
     Real Soon Now.  As I write, the ballot on the document
     has yet to close, but it seems unlikely that any of the
     twenty countries voting will oppose acceptance.  The
     meeting identified a number of trivial editorial
     changes to the current draft international standard,
     and these, taken together with continuing nit-picking
     comments from ISO's central secretariat, should result
     in a document which ISO will print.  Its technical
     content will be identical to that of


                           - 2 -

     ANSI/IEEE Std. 1003.1:1988, so implementors following
     the U.S. standard can be assured of ISO compliance when
     9945-1 finally sees the light of day.

   o POSIX.2, the shell and tools standard, faces a bumpier
     ride before becoming international standard 9945-2.  In
     an ISO ballot on acceptance of draft 9 of IEEE 1003.2
     as a draft international standard, six countries voted
     against, with just five in favour.  This is more of an
     embarrassment than a set-back: hindsight suggests that
     it was just too early to hold a ballot.

   o Showing its increasing concern and frustration at the
     lack of apparent progress within the IEEE on a
     (programming) language-independent version of the POSIX
     operating system interface standard, WG15 has refused
     to "register" the current, largely language-
     independent, draft of the 1003.4 realtime extensions
     standard on the grounds that it makes little sense to
     have language-independent extensions to a base standard
     which is specified in terms of the C language.
     Similarly, the group failed to register 1003.5 (Ada
     binding) and 1003.9 (FORTRAN-77 binding) because
     POSIX.1 lacks an explicit service definition to which
     they can bind.

   o The failure to register these documents causes a hiccup
     -- albeit a discreet one -- in the synchronization
     between IEEE and ISO POSIX standardization schedules.
     In the hope of avoiding such situations in the future,
     an informal "speak now, or forever hold your peace"
     mechanism has been put in place, allowing the
     international community to comment on the subject area,
     format, presentation and approach of IEEE documents at
     an early stage in their preparation.

   o Had it not been for this upset, the working group would
     have adopted a firm synchronization plan so as to
     ensure that the work of IEEE and of ISO is closely
     coordinated in the future.  As it is, the "U.S. member
     body" -- ANSI -- has been asked to provide a revised
     plan for the working group's October meeting in
     Seattle.

   o The Open Software Foundation, UNIX International and
     X/Open are cooperating on a common approach to
     conformance testing, known as Phoenix.  Governmental
     organizations with a strong interest in the field, such
     as the National Institute for Science and Technology
     (NIST) and the Commission of European Communities
     (CEC), seem broadly to welcome this move -- even if the


                           - 3 -

     unaccustomed show of tripartite unity is, as one
     security rapporteur put it, "a bit spooky".

   o At an evening reception hosted by AFUU (Association
     francaise des utilizateurs de UNIX), the French UNIX
     users' group, Mike Lambert of X/Open said that "our
     hand is extended" to the international standardization
     community, with which his organization hopes to work in
     finding some more timely and responsive way of
     delivering formal consensus standards for open systems.
     The definition of this mechanism is left as an exercise
     for the reader -- or for the international standards
     community.  Perhaps Mike has come to realize that
     standardizers too are prone to the Not Invented Here
     syndrome, and so must believe that they thought of
     something themselves before they can accept it.

   o Just to keep us all on our toes, ISO has updated its
     Directives, with the result that the procedure for
     turning a base document -- such as one of the IEEE
     drafts -- into an international standard is subtly
     changed.  We now have to forget about Draft Proposals,
     and turn our minds instead to Working Drafts and
     Committee Drafts.  Sigh...

The rest of this report gives more detail most of these
topics.

            9945-1_--_Operating_System_Interface

You may recall from my report of WG15's last meeting in
October, 1989, that the group had in effect told ISO's
central secretariat that, while the then-current draft of
IS 9945-1 was not perfect, it was, in the group's opinion,
good enough to publish, particularly since we'd undertake to
fix things up on short order, allowing an improved version
to be published within a year of the first edition.

This proposal did not fly.  Firstly, the central secretariat
(now dynamically known as ITTF, the Information Technology
Task Force), refused to publish a document that looked much
more like an IEEE standard than an ISO standard; secondly,
they deemed the changes needed to polish up the draft to be
sufficiently great that it should go out to ballot again in
order to provide a formal check that it was still acceptable
to the group.  This was duly done; the ballot closed on 29th
June, and is expected to pass very comfortably.

Nevertheless, the ballot gave people the opportunity to
comment formally on the document again, with the result that
a number of small bug-fixes and clarifications were


                           - 4 -

suggested, and were accepted for incorporation into the
draft.  We judge -- and we hope that ITTF agrees -- the
changes are strictly editorial, and so will not merit yet
another ballot.  ITTF, which, in discussion with the IEEE,
had slightly bent its drafting and presentation rules so as
to come up with a compromise satisfactory to both parties,
also suggested further changes, some in areas that we
thought had already been addressed.  This is a cause for
concern: the prospect of the standard never being published
because its layout and language do not meet some ill-defined
guidelines does not appeal.  Consequently, we are seeking
"written harmonized editorial requirements" from the IEEE
and ITTF.

The ballot also produced a number of suggestions in the area
of internationalization, such as how to handle (and indeed,
how to refer to) wide, or multi-byte, characters.  To have
acted on these comments would have changed the technical
content of the draft standard -- the equivalent of sliding
down a snake in the game that leads to eventual publication.
Happily, those who suggested the changes were content to
leave these issues for the second edition of the standard,
rather than further delay the first edition.

The single exception that we could get away with was to
replace Annex E's1 example international profile for the
hypothetical (and extremely odd) land of Poz with a real
example for the (only slightly odd) country of Denmark.
Although this is a large change, it can be made because the
annex (ISO-speak for appendix) is "non-normative"; that is,
it is an explanatory example rather than a part of the
official standard.

Messaging, an issue which is currently exercising the minds
of those concerned with the next edition of the 1003.1
standard[1], was also passed over by WG15:  nobody had a
strong preference for either the X/Open proposal or the
UniForum proposal, so 1003.1 will have to handle the issue
without guidance from from the ISO working group.

Where all does this leave us?  With no published
international standard as yet, but with a very good prospect
of having one this year.  Until it arrives, keep using the
bilious green book, IEEE std. 1003.1:19882, as its technical

__________

 1. This material is not in the published
    IEEE std. 1003.1:1988.


                           - 5 -

content is identical to that of the eventual ISO standard.

                 9945-2_--_Shell_and_Tools

Earlier in the year, there had been a ballot on moving
forward draft proposal (DP) 9945-2, Shell and utility
application interface for computer operating system
environments, to become a draft international standard
(DIS).  Basically, while a DP is allowed -- even expected --
to differ considerably from the international standard which
ultimately results, a DIS is expected to be in a format and
to have contents which are very close to those of the
ultimate standard3.  That the ballot was six against to just
five for (with nine countries not voting) indicates that the
consensus is that 9945-2 has to go through quite a few more
changes before it can be acceptable as an international
standard.

Many of these changes concern internationalization, as this
topic affects POSIX.2 considerably more than POSIX.1.  For
example, the example Danish national profile to be
incorporated into 9945-1 is just a part of the work that DS
(Dansk Standardiseringraad) has done on the topic; the rest
affects 9945-2.  There is also an unresolved issue
concerning the definition of collation sequences (sorting
orders) for international character sets.  Utilities such as
sort clearly need to know about collation sequence, and so
do the regular expression-handling utilities and functions
defined by POSIX.2.  The problem is that nobody in ISO seems
to want to handle the matter.  In particular, JTC1/SC2,
which standardizes coded character sets, sees its job as
assigning codes to characters, not as saying anything about
how those codes should sort4.  This is a reasonable
attitude:  collation is a surprisingly complex field, and to

____________________________________________________________

 2. You can buy a copy by calling IEEE customer service on
    [phone] (1 800 678 IEEE inside the U.S.) and
    giving them a credit card number.  The cost is $37, plus
    $4 for overseas surface mail, plus another $15 for
    airmail.  Alternatively, your national standards body
    may be able to sell you a copy.  For example, BSI in the
    U.K. has them for sale at pounds 24.

 3. DP 9945-2 is the last that we will see; under the new
    directives, DPs are no more; they are replaced by
    working drafts (WDs), which become committee drafts
    (CDs) before becoming DISs.  This is not a big deal.


                           - 6 -

attempt to cover it in coded character set standards would
break the ISO rule of one topic, one standard.  This is all
very well, but 9945-2 needs somebody to do the work, and
WG15 may end up doing it itself if pleas for help from
elsewhere in ISO fail.

More work is on the way: 1003.2a, the User Portability
Extension to POSIX.2, was registered for ballot as a
Proposed Draft Amendment (PDAM) to DP 9945-2, giving the
international community a chance to say what it thinks of
the idea of standardizing interactive commands such as vi
and language processors like cc -- or rather c89.

                        Coordination

The coordination arrangements which will make IEEE and ISO
work on POSIX march forward in lock-step were almost
complete before the small international rebellion on the
matter of language independence made us stumble.  (See
below.)  Because WG15 failed to register 1003.4, 1003.5 and
1003.9 at this meeting, the plan must be adjusted, although
little slippage should result.  We'll try to jump on board
the revised plan at the next meeting.

                    Internationalization

In the one and a half days before the main meeting of WG15,
its three rapporteur groups met.  I attended the
internationalization meeting, which had a hectic time of it:
as the only rapporteur group directly concerned with the
current content of 9945-1 and -2, we had a lot of comments
to sift through prior to the main meeting.  This we did, by
the skin of our teeth.  Our conclusions are largely
reflected in the actions on the two drafts, reported above.

                          Security

The security rapporteur group is just getting off the
ground.  As with internationalization, activities scattered
throughout JTC1 have to do with security.  But in contrast
to the current situation for internationalization, for
security there is a (very new) subcommittee, SC27.
Conceivably, SC27 could define some all-encompassing ISO
security model5 which would not suit POSIX and the work of

__________

 4. For oblique confirmation from "the father of ASCII", see
    [2].


                           - 7 -

1003.6, which is eventually to be integrated into the 9945
standards.  The rapporteur group is doing all that it can to
prevent this from happening.  Happily, ISO is already aware
of the issue, and has formed a special working group on
security, to which WG15 will be sending a representative.

                    Conformance_Testing

The proceedings of the rapporteur group on conformance
testing were rather overshadowed by the announcement of
Project Phoenix.  Quite from what ashes this has risen we
did not learn; however, as it involves cooperation between
the Open Software Foundation (OSF), UNIX International and
X/Open, it is difficult to resist the temptation to
speculate.  But resist I shall...

The goal of Phoenix is to develop a common conformance
testing suite and methodology for the three organizations,
or, to put it another way, to harmonize their activities in
this area.  Harmonization of standards for open systems is
an important issue for WG15 in general.  The issue affects
the rapporteur group on conformance testing in particular
because the European Community and NIST are giving a high
priority to accrediting test houses which can check
conformance to open systems standards.  This means that they
need to ensure that uniform test methods are being
consistently applied.  The rapporteur group will address
this issue at its next meeting.  In the mean time, WG15 has
registered the current draft of the first part of 1003.3,
which describes general test procedures, and we will review
it before our next meeting -- despite the fact that there is
as yet no well-defined route by which POSIX.3 can become an
international standard.

                   Language_Independence

The issue of a making the POSIX standards independent of any
particular computer language came to the fore at this
meeting.  What's all the fuss about?  Well, ISO has firm --
and, in my view, sensible -- ideas about how to write
standards which define the services available from
information processing systems.  Building on the doctrine
that one standard should address just one topic, there

____________________________________________________________

 5. ISO likes models, and they're not without their uses.
    Work on a useful model for open systems is under way in
    several forums.


                           - 8 -

should be, says ISO, one document defining the service, and
one or more documents describing ways of accessing that
service.  For example, a browse through the open systems
interconnection standards reveals several groupings such as
IS 8072, Transport Service Definition and IS 8073,
Connection oriented transport protocol specification; and
IS 8649, Service definition for the Association Control
Service Element, and IS 8650, Protocol specification for the
Association Control Service Element6.  Similarly, in text
communication, there is IS 9066-1, Reliable transfer --
model and service definition and IS 9066-2, Reliable
transfer -- protocol specification, and in graphics,
IS 7942, Graphical Kernel System functional description and
IS 8651-1 through -3 giving GKS language bindings for
FORTRAN, Pascal and Ada.  (8651-4, giving bindings for C, is
in the works.)

POSIX, ISO has ordained, must eventually go along with this
model, with the result that IS 9945-1, -2, and -3 (Operating
system interface, shell and utilities, and administration
respectively) will be concerned simply with defining
services, and will not be bound to any particular
programming language.  The key word here is "eventually":
because of the pressing need for an international standard
for POSIX, a waiver has been granted, allowing the first
version of the 9945-1 and -2 standards to be a combination
of (purists might say "a collision between") a service
definition and a C language binding to those services.  The
expectation is that a future revised new edition of each
standard will be language-independent, and that bindings for
the C language will be published as a separate standard at
the same time7.

So far, so good.  But this is where the problems start.
While this mandated future appears a long way off if one
looks at the IEEE's work on POSIX.1, it seems very close

__________

 6. Browsing through OSI standards may be a cure for
    insomnia.  On the other hand, it may aggravate
    hypertension...

 7. Under ISO's procedures, the bindings standards for POSIX
    will be allocated an ISO standard number just as soon as
    we register a base document for one of them.  Until that
    happens, I shall have to refer to "future bindings
    standards", rather than having a convenient number to
    use as a handle.


                           - 9 -

when POSIX.4 (realtime extensions), POSIX.5 (Ada bindings)
and POSIX.9 (FORTRAN-77 bindings) are considered.  In the
case of POSIX.4, language-independent extensions are being
proposed for a standard which is not itself (yet) language-
independent.  And POSIX.5 and POSIX.9 define bindings to a
set of services which is not explicitly defined, but rather
is defined implicitly in terms of the binding to the C
language given in POSIX.1.  In the absence of a clear
service definition, it is no surprise that, for good reasons
which have to do with their respective languages, the Ada, C
and FORTRAN versions of the operating system interface
appear currently to be binding to slightly different sets of
services.

To some, the whole issue of language independence seems like
an unnecessary and irksome imposition by ISO.  In a recent
posting to comp.std.unix[3], Doug Gwyn wrote:

     [Those of us who worked on 1003.1] did NOT set out
     to create a language-independent standard; C was
     specifically chosen for the obvious reason that it
     was the SOLE appropriate language for systems-
     level programming on UNIX, for a variety of
     reasons, including the fact that the UNIX kernel
     has a marked preference for being fed C data
     types.

It is certainly true that, because, back in 1985, all the
base documents for the IEEE POSIX work were written in terms
of a C language interface, the working group made a good
pragmatic decision to produce a standard centered on C.  A
different decision would have resulted in the standard which
took longer to get out of the door, and which would not have
been any more useful to its primary audience -- committed
UNIX users concerned with the divergence among
implementations of their chosen operating system.  But the
success of UNIX and of its offspring, POSIX, has greatly
widened the audience for the standard.  Whether we like it
or not, ISO has revisited the original decision so as to
ensure that the international standards for POSIX meet the
needs of this new audience.  As a result (to continue
quoting from [3]):

     This "language binding" nonsense was foisted off
     on P1003 in an attempt to meet ISO guidelines.  I
     think it must have been adopted by ISO as the
     result of Pascal types insisting that they never
     have to use any other language.

Countering this, I would contend that, while the number of
"Pascal types" is too small for their opinion to be of prime


                           - 10 -

concern, the number of FORTRAN types, COBOL types and
perhaps even of Ada types is large enough that it would be
at least polite to provide some well-defined means whereby
these communities can create bindings which allow them to
hook into POSIX services without having to learn a new
programming language.  In the future, the growing C++
community may decide to define the interface to POSIX
services in an object-oriented manner; Steve Carter paid us
a flying visit with news from the ANSI X3J16 C++ committee
in order to open up channels of communication.

Consider another topic which has come to the fore as POSIX
has moved into the international arena: internationalization
-- mechanisms which will allow non-English speakers to use
POSIX-compliant systems without having to learn a new
natural language.  Like the current movement towards
separating service definitions from bindings, this involves
a considerable amount of work, yet does not appear to
provide much that is of use to UNIX' original community of
technical users.  Accommodating the preferences
(prejudices?) of ever greater numbers of people is, it seems
to me, part of the price of success for the UNIX operating
system.  And it may well pay dividends.  For example,
internationalization work on regular expressions and
collating has resulted in facilities which will be of use
even to English speakers.

Returning to the matter of the programming language used for
bindings, it is true that AT&T-derived UNIX implementations
prefer a diet of C data types.  However, it certainly was an
aim of 1003.1 to allow hosted POSIX implementations, which
might well be riding on underlying operating systems with
entirely different tastes.  As a topical example,
lightweight kernels such as Chorus and Mach live on
messages, suggesting that their services could be bound to a
data stream encoding8.  I suspect that anybody who has tried
to make ioctl() work across a network wishes that UNIX had
anticipated their needs by following such a model from the
start.  But it didn't, and to redefine it in these terms
would be a large piece of work which (thankfully) is a long
way beyond the scope of WG15.

__________

 8. More ISO-speak: broadly, if you have a protocol that
    lives above layer five (session) of the OSI stack, you'd
    better call it a data stream encoding.  For example, the
    protocol for the X Window System is a data stream
    encoding by this definition.


                           - 11 -

There is no way in which all such requirements could have
been anticipated, and accommodating the most important of
them as the need arises inevitably causes pain.  Both
language independence and internationalization are
unanticipated requirements which the international community
wants retrofitted to POSIX on short order.  And it's ANSI,
as provider of the base documents to ISO, and the IEEE, as
the body accredited by ANSI to produce the documents, that
get beat on to do the real work, and to suffer the pain.

In the view of WG15, the real work needed to make POSIX.1 a
logical base for extensions such as POSIX.4, POSIX.5 and
POSIX.9 is not being done fast enough.  Trouble is, all
standards are produced by volunteers -- often volunteers who
have had to make a case to their managements that there's
some percentage in their company being involved in standards
work.  There is clearly an eventual percentage in language
independence for suppliers of POSIX-conformant systems if it
encourages users of languages not traditionally found on
UNIX systems to migrate to POSIX.  But sadly, while not in
any way criticizing the quality of the work done to date,
there aren't enough IEEE volunteers interested in recasting
POSIX.1 into language-independent form.

Maybe, just maybe, if the international community is more
interested than the U.S. in getting this work done, WG15
should encourage more people from outside the U.S. to
participate actively and directly in the work of the IEEE.
(Or, to put it another way, encourage more organizations
outside the U.S. to put their hands more deeply into their
pockets in order to pay for people to attend IEEE POSIX
working group meetings.)  The alternative is that WG15 does
the work itself -- an alternative I'd rather not
contemplate.

For now, two action items on ANSI from WG15 sum up the
situation:

     Pursue with vigour the production of a language-
     independent version of both 9945-1 and P1003.4 in
     conjunction with a C language binding for each in
     order that they are eligible as replacements for
     9945-1:1990.

     Request the IEEE to expedite the completion of the
     language independent specification of 9945-1 that
     is precisely functionally equivalent to the
     existing 9945-1:1990 and provide a C language
     binding that is syntactically and semantically
     identical; and request that a detailed proposal
     status report on this issue including a


                           - 12 -

     synchronization proposal be presented at the next
     meeting of WG15.

                        Next_Meeting

The next meeting of WG15 is in Seattle from 23rd to 26th
October -- the week after the IEEE POSIX working group
meeting in the same city (and the same week as the EUUG
meeting in Nice, France9).  Should be interesting!

__________

 9. In two meetings, WG15 has managed to clash both with
    summer USENIX and with autumn EUUG.  It almost looks as
    if we do it on purpose!  But we don't, and will try to
    do better next year...


                           - 13 -

                         REFERENCES

 1. June, 1990 Standards Update, Jeffrey S. Haemer,
    comp.std.unix Volume 20, Number 66, USENIX, 30 June 1990

 2. Letter from R. W. Bremer, pp 34-35, Byte, volume 15,
    number 6, June 1990

 3. Doug Gwyn, comp.std.unix Volume 20, Number 51, USENET,
    27 June 1990

Volume-Number: Volume 20, Number 110

From [e-mail]  Sat Jul  7 14:02:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23539; Sat, 7 Jul 90 14:02:34 -0400
Posted-Date: 7 Jul 90 14:50:51 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA08156; Sat, 7 Jul 90 13:02:30 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA11586; Sat, 7 Jul 90 13:05:23 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Printing Standards?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
Date: 7 Jul 90 14:50:51 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

In article <[e-mail]> [e-mail] (Mike Urban) writes:
>What incipient or existing standards, if any, specify
>the Shell-level printer interface (lpr and its friends)?

Aha.  That terminal ``r'' tells me you're a Berkeley-ite.  Which is too
bad, I'm afraid.  The draft 1003.2 shell and tools standard specifies a
pretty-much emasculated version of the System V.2 (or thereabouts) lp
print spooling command (which some might argue was fairly impotent in
the first place).  As far as ``friends'' go (lpadmin, enable, lpshut and
so on in the case of System V), none are specified.  This is seen as
1003.7 (administration) territory.  If you can get hold of a draft
(somebody in Rand must have one), you'll find lots of extended
description about how little a conforming application can assume from
lp, and rationale about how it should be possible to implement it as a
shell script, namely

    cat > /dev/lp

The X/Open Portability Guide, edition 3, volume 1, does little better: it
describes a few more options, and the cancel utility, but they're all
optional -- in effect, all an XPG-conformant system has to offer is the
interface described in 1003.2.

All rather depressing really.
--
Dominic Dunlop

Volume-Number: Volume 20, Number 111

From [e-mail]  Sat Jul  7 22:11:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01584; Sat, 7 Jul 90 22:11:11 -0400
Posted-Date: 7 Jul 90 20:42:16 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA28714; Sat, 7 Jul 90 21:11:07 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12643; Sat, 7 Jul 90 21:07:28 cdt
From: J Greely <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Printing Standards?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (J Greely)
Organization: Ohio State University Computer and Information Science
Date: 7 Jul 90 20:42:16 GMT
Apparently-To: [e-mail]

From:  [e-mail] (J Greely)

In article <[e-mail]> [e-mail] (Dominic Dunlop) writes:
[discussion of POSIX specifying only minimal print standard,
bare-bones SysV lp]

>All rather depressing really.

Actually, I find it encouraging.  It means that the world won't
standardize on either SysV *or* Berkeley print spooling, which means
that there's room for someone to write something good.  Lpr and
company are a bitch for a large network, and I wouldn't even *try* to
run lp on 300 machines.  What's needed is a real batch system that
scales to a large network (and please, Ghod, make it administerable by
a mortal).
--
J Greely ([e-mail]; osu-cis!jgreely)

Volume-Number: Volume 20, Number 112

From [e-mail]  Sat Jul  7 22:11:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01598; Sat, 7 Jul 90 22:11:19 -0400
Posted-Date: 7 Jul 90 23:39:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA28727; Sat, 7 Jul 90 21:11:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12709; Sat, 7 Jul 90 21:10:22 cdt
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: portability of tar tapes
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 7 Jul 90 23:39:29 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Henry Spencer)

>From: [e-mail] (Cazier)
>How portable are tar tapes from one machine to another. My experience
>has been that tar within a vendor's site is portable but to try to
>carry a tar 1/4" tape from one vendor to another...

It is necessary to distinguish two issues here:  the tar format, and the
physical recording format.  The latter is whether you can get data off
the tape at all; the former is whether you can understand it.

Tar format is, if anything, significantly more portable than cpio, because
there has basically been only one version of tar format (plus some recent
upward-compatible extensions), whereas there have been several (different
and incompatible) versions of cpio.  The one problem that comes up now
and then is byte-swapping, due to broken hardware/drivers in certain
manufacturer's systems (I won't mention any names, except SGI :-)),
but a simple run through `dd conv=swab' solves that.

Physical recording format, especially on quarter-inch cartridges, is
another can of worms entirely.  There are too many different quarter-inch
recording formats to conveniently count, and new ones keep popping up.
If the recording format of the originating system is incompatible with
that of the reading system, it doesn't matter whether you're using tar,
cpio, ANSI standard magtape format, or whatever -- you *cannot* read
that tape.  Mercifully, there is basically only one format per density
on half-inch tape, and likewise on 8mm, and the appalling mess of floppy
formats settled down considerably when IBM's formats stomped all the
others (well, most of them, we won't mention Apple...) into oblivion.
Unfortunately, as I recall there are two formats on DAT, which isn't a
good start for a new technology.

                                         Henry Spencer at U of Toronto Zoology
                                          [e-mail]   utzoo!henry

Volume-Number: Volume 20, Number 113

From [e-mail]  Sun Jul  8 02:18:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18665; Sun, 8 Jul 90 02:18:36 -0400
Posted-Date: 8 Jul 90 04:23:28 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA17204; Sun, 8 Jul 90 01:18:33 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13109; Sun, 8 Jul 90 00:39:06 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Mandatory Access Controls in the commercial world
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 8 Jul 90 04:23:28 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From:  [e-mail] (Jim Kingdon)
>Thanks for providing some technical details.  But can't the level be
>made a special case of the set of categories?  That is, define
>categories CLASSIFIED, SECRET, TOP_SECRET, etc, and give people either
>{TOP_SECRET, SECRET, CLASSIFIED} or {SECRET, CLASSIFIED} or
>{CLASSIFIED}.  Unless I'm missing something, this provides the same
>functionality and is simpler.

The problem is, that approach could be misadministered to give users
{TOP SECRET, CONFIDENTIAL} or other such erroneous category sets (we
call them "compartments" rather than "categories").  The intent of
the strict CONFIDENTIAL, SECRET, TOP SECRET hierarchy is to rate the
relative probable level of damage to the organizational (national)
interests if the classified information were disclosed to the wrong
parties.  The intent of compartments is to enforce the additional
requirement, beyond one's rated level of trustworthiness, of having
a genuine "need to know" the information.  For example, even though
I might have a TOP SECRET security clearance, if I have not been
specially indoctrinated for access to "special intelligence" then
I am not allowed to access even CONFIDENTIAL SI material.

You might try to redesign such classification schemes, but these
have evolved through many decades of practical experience and seem
to be the best we've been able to devise so far.

Volume-Number: Volume 20, Number 114

From [e-mail]  Sun Jul  8 14:33:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15504; Sun, 8 Jul 90 14:33:11 -0400
Posted-Date: 8 Jul 90 03:20:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25964; Sun, 8 Jul 90 13:33:08 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13798; Sun, 8 Jul 90 13:34:40 cdt
From: VLD/VMB <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on ISO POSIX meeting of June 1990
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 8 Jul 90 03:20:29 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn (VLD/VMB) <[e-mail]>

[ This was originally written as a letter to Dominic, but Doug
agreed it would make a good comp.std.unix posting.  -mod ]

While I don't have any real problem with your use of quotations from
my net posting, I do have a couple of comments on other things you said:

    The ballot also produced a number of suggestions in the area
    of internationalization, such as how to handle (and indeed,
    how to refer to) wide, or multi-byte, characters.

For 1003.1, this is pretty straightforward.  The C requirements on such
character encodings are such that mbc strings can still be handled as
uninterpreted NUL-terminated arrays of char.  In the default "C" locale,
a certain minimum set of characters must be represented, which permits
the construction of portable filename strings.  Even in the "C" locale,
other characters are permitted, so for example a command-line argument
containing "funny characters" can be used directly as an argument to
open() etc.  I know that there are various vendor approaches that make
locales more visible to the operating system, but after all this is UNIX
we're talking about, and one of the main lessons of UNIX is that the
operating system can be designed to be happily oblivious to the uses to
which people put the information that it manages according to simple rules.

I first got involved in "internationalization" issues when I attended a
BOF meeting at which the "expert" who was giving the presentation was
explaining how complex the character set issues were, and when I said
that I didn't see any inherent complexity was berated for my naivety.
Years later, after studying the issues and conversing with the folks
actively working in the field, I still maintain that simple solutions
are possible.  Unfortunately, vendors such as H-P started out with
complicated schemes and have continue to think in those terms.  This
rubbed off on X3J11 when the multibyte character approach was adopted,
which has the obvious problem that anyone programming for an
international environment MUST change from traditional use of C strings
to mbc arrays in his applications.  The Japanese recognize this as an
essential feature of their "long char" proposal, which X3J11 did NOT
intend the mbc approach to be -- however, the fundamental need for
library support using any such approach has now led to the Japanese
requesting that such changes be made for the ISO C standard.  I think
the arguments I used for my alternative proposal to address these very
concerns are being borne out, in spades.

    Returning to the matter of the programming language used for
    bindings, it is true that AT&T-derived UNIX implementations
    prefer a diet of C data types.  However, it certainly was an
    aim of 1003.1 to allow hosted POSIX implementations, which
    might well be riding on underlying operating systems with
    entirely different tastes.

To the contrary, we discussed this very matter in 1003.1 and decided
that, while we did not wish to preclude layered implementations, we
would not make any compromises to accommodate them.  Very definitely
our goal was to develop standards for genuine UNIX variants, not to
provide a "Software Tools" style of Portable Operating System evironment.

We used the same argument when we decided that NFS was simply going to
have to be ruled non-compliant.  UNIX applications rely on certain
semantics of the file system that NFS did not properly support, and we
decided that it would be a disservice to UNIX applications to remove
the requirement that these useful semantics be preserved.

Volume-Number: Volume 20, Number 115

From [e-mail]  Tue Jul 10 03:35:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13238; Tue, 10 Jul 90 03:35:16 -0400
Posted-Date: 9 Jul 90 06:22:37 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01402; Tue, 10 Jul 90 02:35:12 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16476; Tue, 10 Jul 90 02:24:15 cdt
From: Phil Ronzone <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: 9 Jul 90 06:22:37 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Phil Ronzone)

In article <[e-mail]> [e-mail] (Steven M. Schultz) writes:
>    short of soldiers with M16s at a computer facility door i do not
>    believe that software is any substitute for physical security.
>    it's just one more password that has to be spread around (in
>    case the SSO or whoever) goes on vacation, etc...

Argument of two different fruits here.

As an example, we purchased an AT&T 630 (386 PC type machine) to run
AT&T SV/MLS (B1 UNIX). We had AT&T put the software on, and they set,
as is required the passwords.

But they forgot to tell us what the passwords were. Although we had
physical possesion of the machine, in a company that also make computers,
it would have taken us a while to "boot" the system (i.e., insecurely).

And we would have been able to do that ONLY because of the fact that the
machine used standard disks with "standard" UNIX filesystems and so on.

Whereas the same hardware with normal UNIX would have very vulnerable.

A safe protects your money, but if a huge helicopter steals the safe
and you have weeks to work on it, you can open it.



>>I disagree again -- I think the recent Internet worm is an example of why.
>
>    now it's my turn to disagree.  sheesh, why does the worm have to
>    be brought up everytime security is discussed?  it was a BUG that
>    was exploited, and i for one do not think that adding security
>    will do away with BUGs in software.  on the contrary, as the

Eh? That's the WHOLE point of Orange book security and the TCB concept.
Those programs would have never made it into the TCB and been able to
propagate like they did. Although it is not the best example.

The answer was more to WHY would someone want security. Answer is, to
control what you have your system do.
--
<---------------------------------------------------------------------------->
Philip K. Ronzone                  S e c u r e   U N I X           [e-mail]
Silicon Graphics, Inc. MS 9U-500                           work [phone]
2011 N. Shoreline Blvd., Mountain View, CA 94039            fax [phone]

Volume-Number: Volume 20, Number 116

From [e-mail]  Tue Jul 10 03:35:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13267; Tue, 10 Jul 90 03:35:27 -0400
Posted-Date: 9 Jul 90 17:50:35 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01413; Tue, 10 Jul 90 02:35:23 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16541; Tue, 10 Jul 90 02:29:35 cdt
From: John Zolnowsky ext. 33230 <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Summary: _POSIX_n_SOURCE, a source of confusion?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Sun Microsystems, Inc. - Mtn View, CA
Date: 9 Jul 90 17:50:35 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John Zolnowsky ext. 33230)

In article <[e-mail]>, [e-mail] writes:
> Paul Rabin <[e-mail]> reports on the April 23-27 meeting in Salt
> Lake City, UT:
>
> 3.3  Headers and Name-Space Control
>
> A new feature-test macro will be specified by 1003.1b and subsequent
> revisions: _POSIX_1_SOURCE.  This macro takes ordinal values, starting
> with 2 for 1003.1b, and will be incremented by 1 for every subsequent
> revision.  If the value is 1, the effect will be the same as if
> _POSIX_SOURCE were defined.
>
> There are two changes here.  The new name was used to indicate that
> the macro only controls the visibility of identifiers defined in
> POSIX.1.  The usage was changed to allow the value to indicate the
> particular revision or supplement to the standard, rather than having
> to create a new macro each time.  This should simplify the
> construction and maintenance of header files.

I recognize that programs must have some way of freezing the
ever-growing POSIX namespace, but I have reservations about the
approach implicit in the name _POSIX_1_SOURCE.

I suspect that the "1" in _POSIX_n_SOURCE refers to 1003.1, as a
working group or a standard.  This creates a strictly historical
binding between a function name and the working group which first
needed to define an interface, and this binding will be perpetuated in
code.  As an example, imagine the goobledeegook when multi-threaded
network servers must tree-walk and want to be cognizant of symlinks.

Since it is planned that all these standards will be unified under the
umbrella of ISO 9945-1 (or whatever future number the C-binding appears
unders) it would seem more prudent to have a single feature-test macro,
such as _POSIX_C_SOURCE, for which for increasing values expose the
entire POSIX function namespace in historical order.  This would place
no further requirements upon implementations.  Applications would be
affected only when being modified to use POSIX extensions:  they would
then have to honor not only the namespace reservation of the extension,
but of all of POSIX at the time the extension was standardized.  Note
that this requirement already exists for any other interfaces added by
the working group which added the extension.

-John Zolnowsky         [e-mail]              [phone]

Volume-Number: Volume 20, Number 117

From [e-mail]  Tue Jul 10 04:51:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01812; Tue, 10 Jul 90 04:51:06 -0400
Posted-Date: 9 Jul 90 19:01:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05035; Tue, 10 Jul 90 03:51:02 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA17087; Tue, 10 Jul 90 03:36:22 cdt
From: David Dick <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: portability of tar tapes
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 9 Jul 90 19:01:29 GMT
Apparently-To: [e-mail]

From:  [e-mail] (David Dick)

>From: [e-mail] (Cazier)
>How portable are tar tapes from one machine to another. My experience
>has been that tar within a vendor's site is portable but to try to
>carry a tar 1/4" tape from one vendor to another --- that's another story.

The trouble with 1/4 inch tapes is not tar format, but format
of recording data on the tape: there are QIC-11, QIC-24, and QIC-150
(and maybe others).  I'm not even sure that having QIC-11 or QIC-24
is even sufficient.  However, I suspect all the QIC-150s are the same.

David Dick
Software Innovations, Inc. [the Software Moving Company (sm)]

Volume-Number: Volume 20, Number 118

From [e-mail]  Thu Jul 12 08:13:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07313; Thu, 12 Jul 90 08:13:12 -0400
Posted-Date: 10 Jul 90 15:13:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19054; Wed, 11 Jul 90 19:30:10 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19012; Wed, 11 Jul 90 17:41:57 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 10 Jul 90 15:13:29 GMT
Apparently-To: [e-mail]

From:  Jason Zions <[e-mail]>

> Since it is planned that all these standards will be unified under the
> umbrella of ISO 9945-1 (or whatever future number the C-binding appears
> unders) it would seem more prudent to have a single feature-test macro,
> such as _POSIX_C_SOURCE, for which for increasing values expose the
> entire POSIX function namespace in historical order.  This would place
> no further requirements upon implementations.  Applications would be
> affected only when being modified to use POSIX extensions:  they would
> then have to honor not only the namespace reservation of the extension,
> but of all of POSIX at the time the extension was standardized.  Note
> that this requirement already exists for any other interfaces added by
> the working group which added the extension.

This makes the assumption that there is indeed a single POSIX name space,
to which pieces are added by the various working groups. This assumption,
while a reasonable one, is in fact not correct.

The various 1003.* working groups are *not* developing separate components
of an overall, integrated POSIX standard. Each POSIX standard stands alone
from all other POSIX standards *except* where that standard deliberately
requires dependencies. For example, 1003.2 is intended to be implementable
on systems which do not offer a 1003.1-compliant interface. So, a
strictly-compliant 1003.2 application *could not* assume the presence of
1003.1 symbols et al., and would be permitted to make use of names
otherwise reserved to 1003.1. Hence, there needs to be a separate
feature-test macro to activate the 1003.2 name space etc.

Worse yet, it appears that one of the POSIX Real Time Profiles may very
well require only a subset of 1003.1; how on earth does one represent
*that* using the _POSIX_C_SOURCE scheme?

Jason Zions


Volume-Number: Volume 20, Number 119

From [e-mail]  Thu Jul 12 07:43:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01039; Thu, 12 Jul 90 07:43:04 -0400
Posted-Date: 10 Jul 90 15:43:41 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19065; Wed, 11 Jul 90 19:30:21 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19031; Wed, 11 Jul 90 17:42:40 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 10 Jul 90 15:43:41 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Phil Ronzone) writes:
[had a B1 UNIX box]
> But they forgot to tell us what the passwords were. Although we had
> physical possesion of the machine, in a company that also make computers,
> it would have taken us a while to "boot" the system (i.e., insecurely).

And if you needed to use the machine, you would have been out of luck.

For some people that level of security has a negative value. It's that
simple. It's not like we're saying "we want all UNIX systems to be
insecure", we're saying "we don't want all UNIX systems to come with
that level of security". Can't you see the difference?
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>



Volume-Number: Volume 20, Number 120

From [e-mail]  Fri Jul 13 02:24:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15244; Fri, 13 Jul 90 02:24:58 -0400
Posted-Date: 12 Jul 90 03:27:28 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21731; Fri, 13 Jul 90 00:34:40 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20104; Thu, 12 Jul 90 20:17:08 cdt
From: John Michael Sovereign <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Apple Computer
Date: 12 Jul 90 03:27:28 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John Michael Sovereign)


In article <[e-mail]> [e-mail] (Jason Zions) writes:

> This makes the assumption that there is indeed a single POSIX name space,
> to which pieces are added by the various working groups. This assumption,
> while a reasonable one, is in fact not correct.

There is, however, a single C language name space which new standards (and
revisions)
pollute as long as they continue to use header files already defined by
ANSI C and/or POSIX.1
(as I believe Doug Gwyn pointed out recently).

> The various 1003.* working groups are *not* developing separate
components
> of an overall, integrated POSIX standard. Each POSIX standard stands
alone....

>From what I've heard, there HAS been discussion at the ISO level of
bundling the C language
interfaces of POSIX.2 and/or POSIX.4 into future versions of 9945-1.
Unfortunately, a decision on this matter might be delayed until after the
IEEE standards have been adopted....

As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing
_POSIX_SOURCE
can't be used (perhaps modified) for this purpose.

John Sovereign
[e-mail]
"Perhaps software developers should face the same legal support
requirements as parents."


Volume-Number: Volume 20, Number 121

From [e-mail]  Fri Jul 13 11:07:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25188; Fri, 13 Jul 90 11:07:05 -0400
Posted-Date: 11 Jul 90 21:33:56 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21771; Fri, 13 Jul 90 00:34:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20123; Thu, 12 Jul 90 20:17:56 cdt
From: Dave Decot <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Cupertino
Date: 11 Jul 90 21:33:56 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Dave Decot)


> 2.  1003.1a Status
>
> 1003.1a is the recently completed revision to the 1988 POSIX standard.
> No new interfaces or features were introduced, but the text was
> revised in several ways.  The main reason for the revision was to

This is not technically true.

The following new features were added by POSIX.1a:

    ssize_t - signed version of the size_t type
    SSIZE_MAX - constant representing maximum value of ssize_t
    TZNAME_MAX - constant representing maximum length of a timezone name
    _SC_TZNAME_MAX - sysconf() variable argument for TZNAME_MAX
    POSIX_TZNAME_MAX - minimum value of TZNAME_MAX on POSIX.1a systems (it's 3)

The following features were deleted (but are still permitted):

    cuserid() - definition conflicted with most existing practice
    CLK_TCK - non-existent definition imported from ANSI C standard

The following interfaces were changed:
    ssize_t read(int fildes, void *buf, size_t count);
    ssize_t write(int fildes, const void *buf, size_t count);

> The discussion of [the setegid(), etc.] proposal led to a general
> lament about how unclear the group model is in the 1988 POSIX standard,
> perhaps the result of a hasty marriage between the System V and BSD models.
> At the next meeting, the working group intends to add new text to
> P1003.1b to clarify the relation between the effective group ID and
> the supplementary group list.

It seemed rather clear to me.  "Whether the effective group ID is
included in or omitted from the list of supplementary group IDs is
implementation-defined."  In all cases when checking permission to
access something, both the effective group ID and the list of supplementary
group IDs should be compared to the group of the object in question; if
either matches, the access should be granted.

What were the unclarities that were identified?

Dave Decot


Volume-Number: Volume 20, Number 122

From [e-mail]  Fri Jul 13 10:21:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14201; Fri, 13 Jul 90 10:21:51 -0400
Posted-Date: 12 Jul 90 11:36:58 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23079; Fri, 13 Jul 90 00:41:15 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20143; Thu, 12 Jul 90 20:18:39 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on ISO POSIX meeting of June 1990
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
Date: 12 Jul 90 11:36:58 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>


In article <[e-mail]> Dominic Dunlop <[e-mail]>
(that's me) writes of the forthcoming IS 9945-1 (POSIX operating system
interface):

>     Its technical content will be identical to that of
>     ANSI/IEEE Std. 1003.1:1988, so implementors following
>     the U.S. standard can be assured of ISO compliance when
>     9945-1 finally sees the light of day.

I also say the same thing later:

>Where all does this leave us?  With no published
>international standard as yet, but with a very good prospect
>of having one this year.  Until it arrives, keep using the
>bilious green book, IEEE std. 1003.1:1988, as its technical
>content is identical to that of the eventual ISO standard.

A couple of people have pointed out to me that this ain't strictly so:
a few small changes have crept in.  If you say ``almost identical'', you're
more correct -- if a little more worried.  This year's revision of 1003.1
will bring it exactly into line with the eventual ISO standard.

I have asked the respondents to make postings to this group summarizing
the technical differences between the published ANSI/IEEE standard, and
the ANSI/IEEE and ISO standards expected to be published later this
year.  (Thanks in advance.)
--
Dominic Dunlop



Volume-Number: Volume 20, Number 123

From [e-mail]  Sat Jul 14 04:48:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05485; Sat, 14 Jul 90 04:48:29 -0400
Posted-Date: 13 Jul 90 21:07:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14426; Sat, 14 Jul 90 01:05:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21275; Fri, 13 Jul 90 23:54:37 cdt
From: <mindcrf![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Summary: Say NO to feature test macro proliferation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Mindcraft, Inc.
Date: 13 Jul 90 21:07:17 GMT
Apparently-To: [e-mail]

From:  [e-mail]


In article <[e-mail]> [e-mail] writes:
>From:  [e-mail] (John Michael Sovereign)
>In article <[e-mail]> [e-mail] (Jason Zions) writes:
>
>> This makes the assumption that there is indeed a single POSIX name space,
>> to which pieces are added by the various working groups. This assumption,
>> while a reasonable one, is in fact not correct.
>
>There is, however, a single C language name space which new standards (and
>revisions)
>pollute as long as they continue to use header files already defined by
>ANSI C and/or POSIX.1
>(as I believe Doug Gwyn pointed out recently).

>From the 1003.1 standard, 2.8.2:

    Symbols called `feature test macros' are used to control the
    visibility of symbols that might be included in a header.
    Implementations, future versions of this standard, and other
    standards may define additional feature test macros.

My interpretation of this text is that the 1003.1 committee wanted to
provide a mechanism by which a number of standards and implementations
could share the C namespace.  Of course, extended use of this mechanism
is up to the other standards committees and implementors, and is
outside the scope of 1003.1.  Perhaps this is an issue that Dot 0
could help clear up.

>> The various 1003.* working groups are *not* developing separate
>components
>> of an overall, integrated POSIX standard. Each POSIX standard stands
>alone....

Which makes it essential that each standard specify what it assumes
is available from its host, and what it will add to the composite
environment.  While each standard may stand alone, implementations
certainly won't.

>As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing
>_POSIX_SOURCE
>can't be used (perhaps modified) for this purpose.

Because, unlike __STDC__, _POSIX_SOURCE is #defined or not #defined;
its value is not significant.  The implication of the suggestion to use
_POSIX_1_SOURCE for 1003.1a-conforming headers is that the 1003.1
committee is reserving for its own use all feature test macro names
that start with _POSIX_.  This means that the 1003.2 committee will be
on shaky ground if they require that programmers #define
_POSIX_2_SOURCE in order to make 1003.2 symbols visible.

The approach chosen by the ANSI C committee was a good one:  Use a single
name for the feature test macro, and change the macro's VALUE when a
new version of the standard supersedes an old one.
--

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


Volume-Number: Volume 20, Number 124

From [e-mail]  Sat Jul 14 04:39:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03158; Sat, 14 Jul 90 04:39:39 -0400
Posted-Date: 12 Jul 90 23:23:25 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14484; Sat, 14 Jul 90 01:06:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21293; Fri, 13 Jul 90 23:55:25 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: FZI Forschungszentrum Informatik, Karlsruhe, West-Germany
Date: 12 Jul 90 23:23:25 GMT
Apparently-To: [e-mail]

From:  [e-mail]

--- archives and tapes ---

First, I have to admit that I haven't read the latest standard's version,
but I do have strong feelings about data archives and transport.

Both tar and cpio are highly deficient for properly moving information
out and in. The first blunder of all is the limited format that does not
take care of long file names. There is a NAMSIZ parameter, so for heaven's
sake reserve sufficient space in the file descriptor of such a transport
archive! That's so fundamental that I will only talk about one other equally
nasty point about these formats, missing archive and volume labelling.

Next, you have to realize that both tar and cpio already do arrange data
in suitable chunks for transfer ('tar' reads 'tape archive'!). There is
no reason in the world why an ANSI tape file shall not be the envelope
for a UNIX-type archive. On the contrary, this will finally, after all
these years offer data labelling, both on the archive and on the tape
volumes. It is unbelievable that today, 1990, i have to look at a piece of
paper with my tar tape, which tells me about a number of archives on the
same medium and their position. Additionally, the ANSI tar standard
provides multi-volume data sets, so yet another stumbling stone can be
forgotten, if we only wrap tar' and cpio' archives in ANSI tape structures
(where tar' and cpio' are improved versions of tar and cpio).

Then, a point often forgotten: There is a real need to select, duplicate,
store data from some external medium (tape) on a different type of machine
than the one the tape is written on / to be read.  The proposal above will
make that an easy and safe operation, what cannot be claimed today. (Today,
ypou just have to have a guru around who knows alls kinds of different
machines and how they mix).

Finally: Yes, we do move archives across networks, but for most substantial
transfers of data in and out of our machines there is no adequate replacement
for sequential magnetic media. Posix has to take that into account, or we
will be burdened with those problems of today.

Karl Kleine
FZI Forschungszentrum Informatik, Karlsruhe, West-Germany;  [e-mail]



Volume-Number: Volume 20, Number 125

From [e-mail]  Sat Jul 14 04:26:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29533; Sat, 14 Jul 90 04:26:51 -0400
Posted-Date: 12 Jul 90 21:07:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14553; Sat, 14 Jul 90 01:06:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21312; Fri, 13 Jul 90 23:56:04 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 12 Jul 90 21:07:17 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>From:  Jason Zions <[e-mail]>
>Worse yet, it appears that one of the POSIX Real Time Profiles may very
>well require only a subset of 1003.1; how on earth does one represent
>*that* using the _POSIX_C_SOURCE scheme?

Shouldn't 1003.0 step in here and exert some coordination?
1003.1 was deliberately not split into "levels" a la COBOL,
and we meant it.  A Real-Time extension could very well exist
(say, number 1003.123a) and not require that 1003.1 be specified,
but be useless in the absence of some subset of 1003.1 or equivalent,
just as a hosted C implementation on UNIX does not specify that
open() exist, but secretly requires a function with similar
properties in order to be implemented at all.  If the problem is
that the extension wants to contradict some of 1003.1, then it is
an INCOMPATIBLE standard (i.e. one could not specify simultaneous
conformance with 1003.1 and 1003.123a), and I thought that standards
organizations prohibited that.


Volume-Number: Volume 20, Number 126

From [e-mail]  Sat Jul 14 16:28:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05481; Sat, 14 Jul 90 16:28:31 -0400
Posted-Date: 13 Jul 90 04:42:15 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA02215; Sat, 14 Jul 90 15:28:27 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21994; Sat, 14 Jul 90 15:43:12 cdt
From: Norbert Schlenker <[e-mail]>
Newsgroups: comp.std.unix
Subject: How does one criticize P1003.2?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Jul 90 04:42:15 GMT
Apparently-To: [e-mail]

From:  Norbert Schlenker <[e-mail]>

In the mail today, I received a short excerpt out of draft 9 of the
P1003.2 (proposed) standard.  Taking a look at a random page, I came
across the description of fold(1).  It's hardly an important utility,
but it is at least non-trivial.  Thinking a little about how it
could be implemented, I quickly decided that it cannot be done
correctly on machines with finite amounts of memory, because of an
error in specification (details on request).

As I don't have the entire draft, I don't know how to register an
objection -- or at least a request for clarification.  Could someone
tell me how I can do this?

Norbert

P.S.  I hope the fold specification is not indicative of the rest of
      the standard.


Volume-Number: Volume 20, Number 127

From [e-mail]  Sun Jul 15 19:33:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08081; Sun, 15 Jul 90 19:33:52 -0400
Posted-Date: 14 Jul 90 23:27:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00999; Sun, 15 Jul 90 18:33:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22977; Sun, 15 Jul 90 16:55:13 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 14 Jul 90 23:27:34 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)


>Then, a point often forgotten: There is a real need to select, duplicate,
>store data from some external medium (tape) on a different type of machine
>than the one the tape is written on / to be read.  The proposal above will
>make that an easy and safe operation,

Really?  The proposal above will deal with moving stuff from a machine
with a QIC-150-type 1/4" tape drive that can't write QIC-24 tapes to a
machine with a QIC-24-type 1/4" tape drive that can't read QIC-150 or
QIC-120 tapes?  Neat trick!

>what cannot be claimed today. (Today, ypou just have to have a guru
>around who knows alls kinds of different machines and how they mix).

"The proposal above" seems to be "put a 'tar' or 'cpio' archive as one
file within an ANSI-labelled tape."  I fail to see how that makes things
any better; if the problems are with variations between "cpio" and "tar"
formats on different machines, wrapping ANSI labels around the "tar" or
"cpio" data doesn't seem to make things any better.

If the *real* fix is in the "tar'" and "cpio'" formats you list, what do
the ANSI labels buy you other than multi-volume support?

>Finally: Yes, we do move archives across networks, but for most substantial
>transfers of data in and out of our machines there is no adequate replacement
>for sequential magnetic media.

By "data" do you mean "data as opposed to programs"?  If not, do any of
the folks who have retrieved, say, the X11 source via FTP or UUCP have
any comments on the above claim? I sucked the entire X11R3 distribution
to our site via UUCP; I would have done the same with the X11R4 format,
except that somebody already had it and offered to put it on 1/4" tapes
- fortunately, a 1/4" format we can read; they put it on a "tar" tape,
though, so ANSI tape labels contributed nothing....

I suspect the amount of software moved into our site via UUCP is at
least a significant fraction of the amount of software moved into our
site via magtapes.


Volume-Number: Volume 20, Number 128

From [e-mail]  Sun Jul 15 19:34:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08198; Sun, 15 Jul 90 19:34:03 -0400
Posted-Date: 15 Jul 90 01:52:16 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01006; Sun, 15 Jul 90 18:34:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22997; Sun, 15 Jul 90 16:55:54 cdt
From: Sean Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Date: 15 Jul 90 01:52:16 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Sean Fagan)

In article <[e-mail]> [e-mail] writes:
>As an example, we purchased an AT&T 630 (386 PC type machine) to run
>AT&T SV/MLS (B1 UNIX). We had AT&T put the software on, and they set,
>as is required the passwords.
>
>Whereas the same hardware with normal UNIX would have very vulnerable.

Do you honestly believe that, short of encrypting the data on the disk,
sufficient security is going to keep your data "safe" if your machine is
(physicially) compromised?

Uh-huh.
--
-----------------+
Sean Eric Fagan  | "Just think, IBM and DEC in the same room,
[e-mail]    |      and we did it."
uunet!sco!seanf  |         -- Ken Thompson, quoted by Dennis Ritchie




Volume-Number: Volume 20, Number 129

From [e-mail]  Sun Jul 15 19:34:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08257; Sun, 15 Jul 90 19:34:10 -0400
Posted-Date: 14 Jul 90 19:15:16 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01022; Sun, 15 Jul 90 18:34:08 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23015; Sun, 15 Jul 90 16:56:30 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 14 Jul 90 19:15:16 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>From:  [e-mail] (Dave Decot)
>The following features were deleted (but are still permitted):
>    CLK_TCK - non-existent definition imported from ANSI C standard

? Did you also get rid of the times() function?  CLK_TCK was left to
1003.1 by X3J11 for their exclusive use in converting times() results
to/from seconds.  The only thing that SHOULD have been changed is that
1003.1 should not say that ANSI C <time.h> defines CLK_TCK, because it
doesn't.  CLK_TCK should be defined by a 1003.1 implementation, though.


Volume-Number: Volume 20, Number 130

From [e-mail]  Sun Jul 15 19:34:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08568; Sun, 15 Jul 90 19:34:46 -0400
Posted-Date: 14 Jul 90 19:37:46 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01044; Sun, 15 Jul 90 18:34:43 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23035; Sun, 15 Jul 90 16:57:08 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 14 Jul 90 19:37:46 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>>From the 1003.1 standard, 2.8.2:
>    Symbols called `feature test macros' are used to control the
>    visibility of symbols that might be included in a header.
>    Implementations, future versions of this standard, and other
>    standards may define additional feature test macros.
>My interpretation of this text is that the 1003.1 committee wanted to
>provide a mechanism by which a number of standards and implementations
>could share the C namespace.

The feature-test macro provision was the outcome of discussions among
DOnn Terry, Dave Prosser, myself, and a few others in an attempt to
resolve the problem that a single implementation could not simultaneously
conform to IEEE Std 1003.1 and ANS X3.159 due to the strict prohibition
of the latter against implementations defining or declaring non-reserved
identifiers in the standard headers.  Because of the evolutionary history
of the standard headers, some of them contained both UNIX-specific and
OS-independent definitions/declarations; for example, <stdio.h> included
fopen(), which applies in every hosted C environment, and fdopen(), which
is relevant only for UNIX-like environments.  Partly out of legitimate
political concerns, X3J11 refused to allow any special dispensation for
UNIX-specific extensions in the standard C headers, and as a generally
appreciated service to C programmers everywhere forbid conforming C
implementations to add other (non-reserved, i.e. not starting with
underscore etc.) identifiers to the standard headers.  Thus, in effect
other standards such as POSIX, if they are to be compatible with the C
language standard, must not require implementations to define/declare
such names in the headers specified in X3.159.  Yet, P1003 wished to add
some of the traditional UNIX identifiers to those headers.  This is the
problem that the feature-test macro POSIX_SOURCE was intended to solve.
(X3J11 recommended a similar but functionally different solution.)  While
they were at it, P1003 decided that packages other than 1003.1 might also
benefit from feature-test macros, and ended up with the wording you saw.

The technical loophole is that any application that defines _POSIX_SOURCE
has violated a constraint of X3.159, by using a reserved identifier, and
this allows the implementation to act in a non-X3.159-conforming manner,
in this case to define/declare otherwise-prohibited identifiers.

One drawback is that any portable 1003.1-based application that uses any
of the 1003.1 extensions in standard headers will have to predefine the
feature-test macro before including the headers.

There is no such problem with inclusion of headers NOT specified in
X3.159.  Thus, feature-test macros can be avoided simply by specifying
that new facilities be defined/declared in new add-on headers.  This is
much more convenient for the programmer and is highly recommended.
There is no historical-evolutionary problem for new POSIX standards,
and thus there is no need for a mechanism to share the standard headers
for new standards.  Instead of trying to add more cruft to standard C
headers, new inventions should provide their own headers.


Volume-Number: Volume 20, Number 131

From [e-mail]  Mon Jul 16 18:15:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21908; Mon, 16 Jul 90 18:15:41 -0400
Posted-Date: 16 Jul 90 15:16:26 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01475; Mon, 16 Jul 90 15:24:27 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23918; Mon, 16 Jul 90 15:34:43 cdt
From: Jack Jansen <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Terminal size.
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AMOEBA project, CWI, Amsterdam
Date: 16 Jul 90 15:16:26 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Jack Jansen)


This topic has probably been beaten to death already, but I don't follow
this group regularly, so here goes:

I can't seem to find anything in the standard regarding a call to get
the size of a terminal window. Did I miss it, or is there no such call?
If there isn't, are there any plans for adding such a call, and, if so,
is there anybody out there who could make an educated guess as to what
that call might look like?

Please reply by mail, I'll summarize.
--
--
Een volk dat voor tirannen zwicht    | Oral:     Jack Jansen
zal meer dan lijf en goed verliezen    | Internet: [e-mail]
dan dooft het licht            | Uucp:     hp4nl!cwi.nl!jack


Volume-Number: Volume 20, Number 132

From [e-mail]  Tue Jul 17 14:12:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15052; Tue, 17 Jul 90 14:12:01 -0400
Posted-Date: 17 Jul 90 12:53:40 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA08856; Tue, 17 Jul 90 13:11:57 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24800; Tue, 17 Jul 90 12:01:47 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Why perl can't ship as HP/Apollo base software [Perl as standard]
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
Date: 17 Jul 90 12:53:40 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

[Note Followup-To above.  Specify wider distribution if you feel it
appropriate.]

In article <[e-mail]> [e-mail]
(Carlton B. Hommel) writes:
>I've spent several hours over the past few weeks, trying to get perl included as
>part of the next base software release.  It won't happen, for the following
>reasons...
>
>1.  The GNU GENERAL PUBLIC LICENSE
>...
>
>2.  No Support
>...

[Cogent, if besuited, explanations omited -- dig up original posting QUICK if
interested.]
>
>In short, while R&D might think that perl is the best thing since V7, those dreaded
>"business considerations" currently prevent our shipping this truely outstanding
>utility.

Thanks for trying, Carl.

>So, how can perl get into Domain/OS, the Apollo software release?  Well,
>since we, like most other big companies, follow the policy of jumping on whatever
>standards bandwagons come down the pike, if perl makes it into Posix, 1003.?, OSF,
>the next Berkeley distribution, or whatever, then we will pick it up.  However, I'm
>afraid that perl might be just a little too late for any of these efforts.
>
>I've taken a shot at it here at HP/Apollo.  What about other companies?  If I can
>say that our competition is shipping perl, that might swing some weight.  Is anyone
>spearheading an effort to get perl included in the "Real Unix" standards?
>
Not to my knowledge.  Standardizing the shell and tools is quite enough
work for now and the next year or two.  (That's what 1003.2 is doing.)
1003.7, on system administration, might be interested, but they're
currently developing a framework for administration -- trying to work out
what the problem is before they propose a solution -- whereas the philosophy
of perl, as applied to administration, is to make it easier to hack up
ad-hoc solutions (and none the worse for that).
--
Dominic Dunlop



Volume-Number: Volume 20, Number 133

From [e-mail]  Thu Jul 19 01:53:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22990; Thu, 19 Jul 90 01:53:12 -0400
Posted-Date: 17 Jul 90 17:31:40 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15806; Thu, 19 Jul 90 00:53:07 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA26229; Wed, 18 Jul 90 23:12:47 cdt
From: WHITE V L <[e-mail]>
Newsgroups: comp.std.unix
Subject: Shell and Tools FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 17 Jul 90 17:31:40 GMT
Apparently-To: [e-mail]

From:  WHITE V L <[e-mail]>


The last I heard about the POSIX Shell and Tools FIPS was the
draft sent out by Rick Kuhn of NIST on April 13.  At that time, the
FIPS had not yet been published.  What is its current status?

Thanks,

Vicky White
Oak Ridge National Laboratory
Oak Ridge, TN
[e-mail]


Volume-Number: Volume 20, Number 134

From [e-mail]  Thu Jul 19 01:53:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23037; Thu, 19 Jul 90 01:53:22 -0400
Posted-Date: 17 Jul 90 18:23:12 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15840; Thu, 19 Jul 90 00:53:17 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA26248; Wed, 18 Jul 90 23:13:29 cdt
From: Bob Lenk <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 17 Jul 90 18:23:12 GMT
Apparently-To: [e-mail]

From:  Bob Lenk <[e-mail]>

>The following features were deleted (but are still permitted):
>    CLK_TCK - non-existent definition imported from ANSI C standard

As of 1003.1a/D5 (also ISO/IEC DIS 9945-1.2), CLK_TCK is still required
to be defined in <time.h>.  It is obsolescent.  It is mentioned only
in one subclause (4.8.1.5), and is not used to define or describe any
other functionality.  Most features (such as times() are now described
in terms of "clock ticks".  Since it is no longer in the C Standard, it is
not mentioned in 2.7.1 (as in 1003.1-1988); the index seems to have an
erroneous reference to that deleted mention.

I don't know of any changes to this since that draft/DIS.

        Bob Lenk
        [e-mail]
        hplabs!hpfcla!rml


Volume-Number: Volume 20, Number 135

From [e-mail]  Tue Jul 24 01:34:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27142; Tue, 24 Jul 90 01:34:39 -0400
Posted-Date: 19 Jul 90 18:04:02 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00133; Mon, 23 Jul 90 22:49:39 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00699; Mon, 23 Jul 90 22:41:45 cdt
From: Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Shell and Tools FIPS
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The MITRE Corp., Bedford, MA
Date: 19 Jul 90 18:04:02 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Cazier)

You can write to [e-mail] or call Roger Martin at the NIST
at 301-975-3295 to get more info.


Volume-Number: Volume 20, Number 136

From [e-mail]  Tue Jul 24 01:44:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29749; Tue, 24 Jul 90 01:44:28 -0400
Posted-Date: 20 Jul 90 05:29:50 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00145; Mon, 23 Jul 90 22:49:48 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00720; Mon, 23 Jul 90 22:42:41 cdt
From: John G. DeArmond <rsiatl![e-mail]>
Newsgroups: comp.std.unix
Subject: Shipping Perl
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and gun works facility)
Date: 20 Jul 90 05:29:50 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John G. DeArmond)


[e-mail] (Dominic Dunlop) writes:


>>So, how can perl get into Domain/OS, the Apollo software release?  Well,
>>since we, like most other big companies, follow the policy of jumping on whatev
>er
>>standards bandwagons come down the pike, if perl makes it into Posix, 1003.?, O
>SF,
>>the next Berkeley distribution, or whatever, then we will pick it up.  However,
> I'm
>>afraid that perl might be just a little too late for any of these efforts.
>>
>>I've taken a shot at it here at HP/Apollo.  What about other companies?  If I c
>an
>>say that our competition is shipping perl, that might swing some weight.

[repeat after me "hit <enter> after 79 columns :-)]

One of my clients is GTE and they'll be shipping Perl the next release
of one of their major products.  contact me by email if you are
interested in the details.

Sounds like all you REALLY gotta do is get your lawyers to READ the
LICENSE.  Even a dumb lawyer can understand it.

John




--
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**


Volume-Number: Volume 20, Number 137

From [e-mail]  Wed Jul 25 11:13:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02968; Wed, 25 Jul 90 11:13:57 -0400
Posted-Date: 23 Jul 90 23:20:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23399; Wed, 25 Jul 90 10:08:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05314; Wed, 25 Jul 90 08:06:46 cdt
From: Ron Guilmette <lupine![e-mail]>
Newsgroups: comp.std.unix
Subject: vexec function(s)?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: lupine![e-mail]
Organization: Network Computing Devices, Inc., Mt. View, CA
Date: 23 Jul 90 23:20:32 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Ron Guilmette)


Just a trivia question.

On very rare occasions, I have found the family of vprintf functions (i.e.
vprintf, vfprintf, and vsprintf) quite useful.  In certain cases, there
is simply no other way to accomplish quite the same thing (especially
on the newer RISC machines where methods of passing variable numbers of
parameters can get rather complicated).

Now I'm looking at a hunk of non-portable code (written by somebody else
of course :-) that I have to port. and this code involves a call to execvp.
It looks kinda like:

------------------------------------------------------------------------------
different_execvp (a, args)
char    *a;
va_list args;
{
    char **argv;

    argv = (char **) args;        /* YIKES!!! */
    argv[0] = basename(argv[0]);
    execvp(a, argv);
}
------------------------------------------------------------------------------

The line with the comment /* YIKES!!! */ gets errors during compilation due
to a severe type mishmash for the assignment.  That's due to the fact that
(on the machine I am compiling on, the type used for `va_list' is most
definitely *not* a type which can be legally typecast to a pointer.  (Hint:
it is a struct on this type of RISC machine.)

What I appear to need here is either:

    a)  a standard way to convert a va_list into a list of pointers
        (to argument values), or

    b)  a standard way to modify one element of a va_list *and* a
        standard function like:

        int vexeclp (char *name, va_list vargs);

None of these things are a part of standard ANSI C (as far as I know).
Are any of them a part of POSIX?  If not, why not?



Volume-Number: Volume 20, Number 138

From [e-mail]  Wed Jul 25 11:10:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02112; Wed, 25 Jul 90 11:10:43 -0400
Posted-Date: 23 Jul 90 22:07:06 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23504; Wed, 25 Jul 90 10:10:27 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05342; Wed, 25 Jul 90 08:07:49 cdt
From: Roland McGrath <[e-mail]>
Newsgroups: comp.std.unix
Subject: _POSIX_VDISABLE
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hackers Anonymous International, Ltd., Inc. (Applications
Date: 23 Jul 90 22:07:06 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Roland McGrath)


>From 1003.1 2.10.4 it seems that if _POSIX_VDISABLE is defined as -1 in
<unistd.h>, it is supposed to mean there is no VDISABLE value for any file.
This precludes the value being -1.  Was this the intent?

Similarly, 5.7.1.3 says:

If the variable corresponding to NAME has no limit for the path or file
descriptor, the pathconf() and fpathconf() functions shall return -1 without
changing `errno'.

Though in the case of NAME == _PC_VDISABLE, the value in question is not a
"limit", this seems to imply that if pathconf("file", _PC_VDISABLE) returns -1
without changing `errno', then there is no VDISABLE for value for "file".

The problem is that the wording of the standard and the sysconf, pathconf, and
fpathconf functions were designed for boolean options and for limits which are
required to be positive integers.  In these cases, -1 is a reasonable
out-of-range value.  But _POSIX_VDISABLE is a character value, not restricted
to any specific range, and doesn't fit in right.
--
    Roland McGrath
    Free Software Foundation, Inc.
[e-mail], uunet!ai.mit.edu!roland


Volume-Number: Volume 20, Number 139

From [e-mail]  Wed Jul 25 11:11:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02302; Wed, 25 Jul 90 11:11:19 -0400
Posted-Date: 24 Jul 90 21:31:58 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23514; Wed, 25 Jul 90 10:10:35 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05371; Wed, 25 Jul 90 08:09:16 cdt
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Thanks, g.m.
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 24 Jul 90 21:31:58 GMT
Apparently-To: [e-mail]

From: [e-mail] (John S. Quarterman)

Thanks to John B. Chambers <[e-mail]> for acting
as guest moderator while I was away at the IEEE/CS TCOS
standards committee meetings in Danvers last week, and
elsewhere before that.  Good job, g.m....

John S. Quarterman <[e-mail]> moderator comp.std.unix

Volume-Number: Volume 20, Number 140

From [e-mail]  Thu Jul 26 17:50:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09007; Thu, 26 Jul 90 17:50:33 -0400
Posted-Date: 24 Jul 90 22:29:02 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25333; Thu, 26 Jul 90 16:50:30 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09893; Thu, 26 Jul 90 15:48:53 cdt
From: Karl Heuer <[e-mail]>
Newsgroups: comp.std.unix
Subject: functions and headers
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 24 Jul 90 22:29:02 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Karl Heuer)

In which header should ctermid() and cuserid() be declared?  Traditionally
they have been found in <stdio.h>, which is where their L_ constants are
defined, but they aren't listed there in 2.8.3.  Is this an oversight which
is being corrected in a supplement, or do these functions go in <unistd.h>
(as implied by the default clause of 2.8.3)?

How about popen() and pclose()?  These aren't listed in 1003.1 at all,
presumably because they use shell syntax and so they're described by 1003.2.
Should they go in <stdio.h>, <unistd.h>, or nowhere?  (XPG3 says they're
declared in <stdio.h>, but does not mark this as an extension over POSIX.)

Karl W. Z. Heuer ([e-mail] or ima!kelp!karl), The Walking Lint

Volume-Number: Volume 20, Number 141

From [e-mail]  Thu Jul 26 17:50:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09047; Thu, 26 Jul 90 17:50:45 -0400
Posted-Date: 24 Jul 90 19:52:22 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25344; Thu, 26 Jul 90 16:50:38 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09912; Thu, 26 Jul 90 15:49:48 cdt
From: Rick Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Shell & Util FIPS Wkshp.
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 24 Jul 90 19:52:22 GMT
Apparently-To: [e-mail]

From: Rick Kuhn <[e-mail]>

                       NIST POSIX Workshop

                  POSIX Commands and Utilities

                        September 6, 1990

A workshop will be held September 6, 1990 to discuss the proposed
Federal  Information  Processing  Standard for POSIX Commands and
Utilities.  The proposed FIPS  is  based  on  Draft  9  of  POSIX
1003.2.   The workshop will explain the contents of POSIX 1003.2,
the exclusions specified in the FIPS proposal,  and  the  use  of
FIPS  in  Federal  procurements.    Comments on the proposed FIPS
will be solicited.  The workshop is open to all  interested  par-
ties.  Both Federal agency personnel and vendors implementing PO-
SIX systems are encouraged to attend.

The workshop will be held September 6, 1990  at  NIST,  Gaithers-
burg,  Md.  For information on the workshop, or to register, con-
tact

                Jim Hall
                Technology Bldg.  B266
                NIST
                Gaithersburg, Md.  20899
                301/975-3273
                301/590-0932  FAX
                [e-mail]

Volume-Number: Volume 20, Number 142

From [e-mail]  Thu Jul 26 17:51:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09145; Thu, 26 Jul 90 17:51:01 -0400
Posted-Date: 24 Jul 90 22:03:57 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25353; Thu, 26 Jul 90 16:50:48 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09946; Thu, 26 Jul 90 15:51:01 cdt
From: Karl Heuer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_VDISABLE
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 24 Jul 90 22:03:57 GMT
Apparently-To: [e-mail]

In article <[e-mail]>:
>From: [e-mail] (Roland McGrath)
>The problem is that the wording of the standard and the sysconf, pathconf, and
>fpathconf functions were designed for boolean options and for limits which are
>required to be positive integers.  In these cases, -1 is a reasonable
>out-of-range value.  But _POSIX_VDISABLE is a character value, not restricted
>to any specific range, and doesn't fit in right.

The documented use of _POSIX_VDISABLE is to store it in an object of type
cc_t.  This is defined in 7.1.2.1 to be an unsigned integral type; hence -1
is indeed out-of-band.  Unless you're trying to make cc_t an unsigned long and
have _POSIX_VDISABLE be ULONG_MAX, you should be okay.

Karl W. Z. Heuer ([e-mail] or ima!kelp!karl), The Walking Lint

Volume-Number: Volume 20, Number 143

From [e-mail]  Thu Jul 26 17:51:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09255; Thu, 26 Jul 90 17:51:21 -0400
Posted-Date: 25 Jul 90 09:49:41 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25370; Thu, 26 Jul 90 16:50:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA10019; Thu, 26 Jul 90 15:53:32 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.wizards
Subject: Re: Location of seek pointer after read error?
Summary: SunOS behaviour is actually POSX conformant
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.std.unix
Organization: The Standard Answer Ltd.
Date: 25 Jul 90 09:49:41 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

[Moderator: please cross-post to comp.unix.wizards -- or let me know that
you won't cross-post to unmoderated groups]

[I prefer not to cross post, but I sometimes do so if the number of
newsgroups is small, the subject matter is appropriate, and especially
if there's a Followup-To.  -mod]

In article <[e-mail]> [e-mail]
(Roy Smith) writes:
>The SunOS-3.5.2 man page for read(2) says:
>
>    On objects capable of seeking, the read starts at a position
>    given by the pointer associated with d (see lseek(2)).  Upon
>    return from read, the pointer is incremented by  the  number
>    of bytes actually read.
>
Ah.  Isn't this interesting?  Here's what POSIX.1 (ANSI/IEEE Std.
1003.1:1988) has to say:

    On a regular file or other file capable of seeking, read() shall
    start at a position in the file given by the file offset associated
    with fildes.  Before successful return from read(), the file
    offset shall be incremented by the number of bytes actually read.

>Now, if you are reading from a raw disk partition (say /dev/rxy0a) and get
>a read error (because, for example, there is a bad block on the disk),
>where should the pointer be after the read(2) call returns?  It turns out
>that, at least for SunOS-3.5.2, the pointer is incremented, as if the bytes
>in the bad block had actually been read.  I would consider this incorrect
>behavior.  Do you agree?
>
Looking at the tighter and arguably sneakier wording of the standard,
it appears that all bets are off as to the value of the file offset
after an error.  Sure enough, the rationale says:

    The standard does not specify the value of the file offset after an
    error is returned; there are too many cases.  For programming
    errors, such as [EBADF], the concept is meaningless since no file
    is involved.  For errors that are detected immediately, such as
    [EAGAIN], clearly the pointer should not change.  After an
    interrupt or hardware error, however, an updated value would be
    very useful, and this is the behavior of many implementations.

    References to actions taken on an ``unrecoverable error'' have been
    removed [from the standard].  It is considered beyond the scope of
    this standard to describe what happens in the case of hardware
    errors.

So, you'll be nonplussed to learn that SunOS' behaviour, which I agree is
less useful than it could be, is POSIX-conformant.

>[Description of writing program which repeatedly seeked back to start of
>failing blocks, and so eventually recovered slightly soft errors deleted.]

Should Sun wish to modify their drivers so that the file pointer points to
the start of a failing block after an error, that behaviour too would be
POSIX conformant.   You can't legislate for everything...

>"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

Wouldn't be POSIX either...
--
Dominic Dunlop

Volume-Number: Volume 20, Number 144

From [e-mail]  Thu Jul 26 17:51:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09251; Thu, 26 Jul 90 17:51:20 -0400
Posted-Date: 25 Jul 90 18:24:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25378; Thu, 26 Jul 90 16:51:10 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA10045; Thu, 26 Jul 90 15:55:19 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: vexec function(s)?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 25 Jul 90 18:24:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>What I appear to need here is either:
>
>    a)  a standard way to convert a va_list into a list of pointers
>        (to argument values), or

I suspect "different_execvp" is misnamed; given the "va_list", it
appears to have a calling sequence more like "execlp" - i.e.,

    different_execlp("/bin/explode", "explode", "bright blue light",
        (char *)NULL);

Given that, you could scan the argument list twice; the first time,
you'd count the number of arguments, then you'd malloc up an array of
N+1 "char *"s, and scan the argument list a second time filling in that
array.  Now "argv" is a pointer to the first element of that array....

>None of these things are a part of standard ANSI C (as far as I know).

The second isn't; the first can be done in ANSI C, unless I've missed
something subtle in the spec that forbids traversing the argument list
twice (I just checked and didn't see anything obvious).

>Are any of them a part of POSIX?

Nope.

>If not, why not?

Because the first can be done in ANSI C (or pre-ANSI C with <varargs.h>).

Volume-Number: Volume 20, Number 145

From [e-mail]  Thu Jul 26 17:51:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09333; Thu, 26 Jul 90 17:51:34 -0400
Posted-Date: 26 Jul 90 00:12:42 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25387; Thu, 26 Jul 90 16:51:19 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA10074; Thu, 26 Jul 90 15:56:48 cdt
From: Roland McGrath <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: vexec function(s)?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hackers Anonymous International, Ltd., Inc. (Applications
Date: 26 Jul 90 00:12:42 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Roland McGrath)

In article <[e-mail]> [e-mail] (Ron Guilmette) writes:
   What I appear to need here is either:

       a)  a standard way to convert a va_list into a list of pointers
           (to argument values), or

       b)  a standard way to modify one element of a va_list *and* a
           standard function like:

           int vexeclp (char *name, va_list vargs);

   None of these things are a part of standard ANSI C (as far as I know).
   Are any of them a part of POSIX?  If not, why not?

A would fall under the C standard, and B under 1003.1.  However, neither of
these exist.  I imagine the answer the appropriate committees would give would
be "insufficient utility".

At any rate, you can handle the case in question by doing A manually, since
`execlp' has a defined way of determining its number of arguments:

{
  char **argv[ARG_MAX];
  register unsigned int i = 0;
  va_list args;

  va_start(args, lastarg);

  do
    argv[i] = va_arg(args, char *);
  while (argv[i++] != NULL);
}

(Actually, I would suggest dynamically allocating ARGV to avoid eating all your
memory if ARG_MAX is very large.)
--
    Roland McGrath
    Free Software Foundation, Inc.
[e-mail], uunet!ai.mit.edu!roland

Volume-Number: Volume 20, Number 146

From [e-mail]  Thu Jul 26 17:51:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09561; Thu, 26 Jul 90 17:51:54 -0400
Posted-Date: 26 Jul 90 17:36:58 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25396; Thu, 26 Jul 90 16:51:31 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA10107; Thu, 26 Jul 90 15:58:28 cdt
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Son of WeirdNIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Jeffrey S. Haemer <[e-mail]>
Date: 26 Jul 90 17:36:58 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>

                          Son of WeirdNIX

                         USENIX Association

                            23 July 1990

    Norman Bangerter, Governor of Utah, declared April 23-27
    ``POSIX week'' in the state of Utah.  Spurred on by the
    spirit of that declaration, the USENIX Association is
    announcing its 1990 POSIX contest.

    Prizes (besides notoriety) include

       + a copy of the ``POSIX Week'' declaration,

       + an official, 40-foot, red-and-white ``Welcome POSIX''
         banner,

       + and -- thanks to UNISYS and the state of Utah --
         + two round-trip tickets to Salt Lake City, plus
         + weekend accommodations at a hotel yet to be named.

    If you were at the Snowbird meetings, or have ever been to
    Utah for any reason, you'll know this is a great prize.  If
    you haven't, take our word for it.

    ``What,'' you're asking, ``do I have to do to win?''
    Designing a contest isn't easy.  We toyed with the idea of
    holding a Roger Martin look-alike contest.  We almost
    decided on, ``If POSIX were made into a movie, who would
    play the attendees?'' [Sample answer: Jack Nicholson as Jim
    Isaak (Jim says he'd prefer ``Cary Grant''), Oscar the
    Grouch as John Quarterman, ...]

    Finally, we decided on a second, not-at-all-annual, WeirdNIX
    Contest.  As with the first one, which is described in
    section B.1.2.12 of ANSI/IEEE 1003.1-1988, the goal is to
    find:

     the best new and technically legal interpretation of the POSIX standard
     which nevertheless violates the intuitive intent of the POSIX standard.

    Both

       + 1003.1 (``The Ugly Green Book''), and

       + 1003.2 (draft 10 or later)

    are fair game.  The former is available from


                    - 2 -

         IEEE Service Center
         445 Hoes Lane
         Piscataway, NJ  08854
         U.S.A.
         [phone]

    the latter from

         Lisa Granoien
         IEEE Computer Society
         1730 Massachusetts Ave NW
         Washington, DC 20036-1903
         [phone]

    While the only version of 1003.1 currently available is IEEE
    1003.1-1988, we won't give high marks to cheap shots, so
    problems fixed in IEEE 1003.1-1990 (soon to be published,
    and formerly found in documents labeled 1003.1a) aren't good
    targets.

    In the earlier contest, separate prizes were awarded for
    ``Best'' and for ``Most Demented.'' We debated doing this
    again but, in the end, decided that one prize of two tickets
    makes more sense than two prizes of one ticket.  The judges
    may choose to announce winners in a variety of categories,
    but the prize mentioned above is a grand prize: we'll award
    the prize to whichever entry we think is the best, whatever
    its orientation.

         Judges are:

         Donn Terry (Chair, 1003.1),
         Hal Jespersen (Chair, 1003.2),
         N. Ray Wilkes, (Vice chair, 1003.3),
         John Quarterman (USENIX Standards liaison), and
         Jeffrey S. Haemer (USENIX report editor).

    Please mail entries to Jeffrey S. Haemer <[e-mail]>.
    If you don't get an acknowledgement, I haven't gotten it.
    Previous winners may compete, but previous entries aren't
    allowed.

    Entries must be submitted by November 21, 1990, to give us
    time to judge them.

    We'll announce the winner at the Winter USENIX Conference in
    Dallas, January 21-25, 1991.

Volume-Number: Volume 20, Number 147

From [e-mail]  Mon Jul 30 01:27:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09268; Mon, 30 Jul 90 01:27:56 -0400
Posted-Date: 28 Jul 90 23:00:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23438; Mon, 30 Jul 90 00:27:54 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16269; Sun, 29 Jul 90 23:25:50 cdt
From: John F. Haugh II <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Saved-Set-IDs v. System V
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jul 90 23:00:20 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John F. Haugh II)

Peter Jeffe has managed to convince me that there is something flawed in
my reading of 4.2.2, and the associated pieces of 1003.1 related to the
feature test macro _POSIX_SAVED_IDS.

The rationale, in B.4.2.2, claims that this functionality is derived from
System V and is designed to permit the application to toggle between the
effective ID of the process and the real ID of the process creator.

The conflict between 4.2.2.2 and System V setuid is that System V states

    "If the effective user ID of the calling process is super-user,
     the real user (group) ID and effective user (group) ID are set
     to uid (gid)."

and 4.2.2.2 states

    "(1) If the process has appropriate privileges, the setuid()
     function sets the real user ID, effective user ID, and the
     saved set-user-ID to uid."

The first problem is that a program which is set-user-ID to an ID other
than super-user will behave quite differently when executed by root.  The
first execution of "setuid (real_uid)" will change the effective user ID
to a process which "has appropriate privileges" so that the second
execution of "setuid (effective_uid)" will permanently change the process
back to "effective_uid".  The second problem relates to processes which
are set-user-ID to super-user.  The first execution of "setuid (real_uid)"
is going to permanently change the IDs so that the process can never
switch back to the original saved set-user-ID.

Contrary to the rationale, this behavior does not permit the application
to toggle between the real and saved set-user-ID unless both are not the
super-user's ID.  So, how does an application toggle between a non-super
user and a super-user?
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]

Volume-Number: Volume 20, Number 148

From [e-mail]  Mon Jul 30 17:38:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07616; Mon, 30 Jul 90 17:38:45 -0400
Posted-Date: 29 Jul 90 22:05:03 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14762; Mon, 30 Jul 90 16:38:43 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18318; Mon, 30 Jul 90 16:50:20 cdt
From: Arnold Robbins <[e-mail]>
Newsgroups: comp.std.unix
Subject: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: <samsung.com!audfax![e-mail]>
Organization: AudioFAX Inc., Atlanta
Date: 29 Jul 90 22:05:03 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Arnold Robbins)

Can someone with access to the 1003.1 standard tell me if the utime(2)
system call is standardized, and if so if the definition of struct utimbuf
is supposed to be in a particular header file?

While we're at it, can anyone tell me why the stupid structure never
made it into <sys/types.h>, and instead has to be redeclared over and over
and over again from the man page??!?  Sheesh.

As they used to say in ancient net history,

``Thanks In Advance,''
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #220 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail]    Phone: [phone] | number of children.
UUCP:      emory!audfax!arnold    Fax:   [phone] |   -- Miriam Robbins

Volume-Number: Volume 20, Number 149

From [e-mail]  Tue Jul 31 14:49:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05795; Tue, 31 Jul 90 14:49:03 -0400
Posted-Date: 31 Jul 90 00:53:12 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA17537; Tue, 31 Jul 90 13:49:00 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20043; Tue, 31 Jul 90 13:49:19 cdt
From: Donn Holtzman <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX ACL Definition
Keywords: security, ACLs
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Donn Holtzman)
Organization: NCR Corporation, Rancho Bernardo
Date: 31 Jul 90 00:53:12 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Donn Holtzman)

Is there a POSIX standard which defines Access Control Lists (ACLs)?
If so could someone please send me (via email) the name and number of
the standard? I also need to know the best way to get a copy.

Thanks

Donn Holtzman
NCR E&M San Diego, MS9114
16550 W. Bernardo Dr.
San Diego, CA 92127

Volume-Number: Volume 20, Number 150

From [e-mail]  Tue Jul 31 14:49:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05992; Tue, 31 Jul 90 14:49:23 -0400
Posted-Date: 31 Jul 90 16:47:04 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA17561; Tue, 31 Jul 90 13:49:15 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20065; Tue, 31 Jul 90 13:50:11 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, U.S. TAG to ISO/IEC JTC1 SC22 WG15
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 31 Jul 90 16:47:04 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              July, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

U.S. TAG to ISO/IEC JTC1 SC22 WG15

Susanne Smith <[e-mail]> reports on the June 1 meeting in
Denver, Colorado:

1.  Overview

Before you ask, ISO/IEC JTC1 SC22 WG15 is ISO POSIX.  The U.S. TAG is
the United States Technical Advisory Group, which formulates the U.S.
position on WG15 issues and chooses the U.S. delegation to WG15
meetings.

The TAG usually meets in conjunction with the IEEE POSIX meetings.
The June 1 meeting was a special meeting, held to complete the many
unfinished tasks left from Snowbird and ready the instructions to the
U.S. delegation before the June 11 WG15 meeting.

2.  Two vacant positions

Terry Dowling, vice-chair and security rapporteur, resigned after the
New Orleans meeting in January.  Currently there are no candidates for
the vice-chair position.  Donn Terry has been assuming the
responsibilities in the interim.

A rapporteur group is a group of technical experts that discusses
specialized aspects of a particular standards effort.  The specialized
aspects usually have a broader scope than an individual standard and
require coordination of effort between standards bodies.  WG15 has
three: internationalization, security, and conformance.  The TAG
currently has rapporteurs for internationalization (Donn Terry) and
conformance (Roger Martin).  John Hill and Al Weaver said that they
would be able to cover the June 11 security meetings in Paris.

__________

  * UNIXTM is a Registered Trademark of UNIX System Laboratories in
    the United States and other countries.

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15


                - 2 -

3.  Some important decisions from Snowbird

3.1  Profile groups get help

SC22 asked WG15 to develop a plan to help groups writing profiles.  (A
profile is an application-area-specific set of pointers to standards.
For example, P1003.10 is developing a supercomputing profile.) Wearing
his WG15-convener hat, Jim Isaak drafted and submitted a ``POSIX
Harmonization Proposal'' --  a plan that gives profile groups a way to
observe WG15 meetings and participate when their proposals are being
considered.  The plan lists the responsibilities of both the
``harmonization liaison'' and WG15.  The TAG approved the plan with
comments, including changing ``harmonization'' to ``coordination.''
[Editor: I think ``harmonization'' is ugly, but it does parallel the
``MUSIC'' acronym that's gaining ground in the UNIX, er, ``Open
Systems'' arena.]

3.2  Speeding international approval

SC22 has asked all working groups doing development work in national
bodies (for example, WG15 and IEEE P1003) to find a way to synchronize
their national and international efforts.  Such synchronization will
help eliminate delays between national-body approval and ISO approval;
it will also insure that both national and international bodies use
the same text and speed achieving a broad consensus by circulating
them in both bodies simultaneously.

Donn Terry, TAG chair, and Jim Isaak (him again?) shouldered the
burden of developing the plan and submitted it at Snowbird.  The meat
of the proposal is the following synchronization process:

   - SC22 review and comment

   - IEEE balloting; document ready for broad comment

   - U.S. recommends CD registration be requested by WG15.  (CD,
     Committee Document, is now used instead of DP Draft Proposal.)

   - CD comments fed to IEEE balloting; IEEE recommendations fed to CD
     process

   - IEEE final approval delayed until updated draft is suitable for
     DIS registration

   - DIS and ANSI approval run in parallel; substantive feedback from
     DIS ballot creates an IEEE PAR

Final authority to approve or reject the plan rests with SC22 and the
IEEE Computer Society Standards Activities Board, but the TAG voted
``No with binding comments,'' objecting to a few details.  If the
problems listed below are fixed, the vote will automatically change to

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15


                - 3 -

``Yes.''

   + Under the plan, TCOS/SEC documents, such as standards drafts and
     administrative status reports, would all be sent to WG15 and SC22
     to encourage feedback before balloting.  The plan would force
     TCOS working groups to use the JTC1 format for draft documents.
     Currently POSIX documents use a unique TCOS format, so the TAG
     objected to this requirement but added the comment that the
     format should be one approved by the ITTF (Information Technology
     Task Force, formerly, the ``Central Secretariat'').

   + The TAG also objected to the requirement that TCOS meet outside
     of the U.S. mainland every 12 to 18 months to encourage
     international participation.  It did not object to meeting
     outside the U.S., but thought the requirement did not belong in
     the plan.

4.  Decisions made in this meeting

4.1  Formatting nits still block ISO UNIX

The 9945-1 document (the ISO version of 1003.1) still has problems.
WG15 recommended registering it as an International Standard (IS), but
is now stuck in a loop: ISO demands a format change, the IEEE makes
the change, then ISO finds a new formatting problem.  The TAG thinks
this loop has gone on long enough, and recommended that WG15 form an
ad hoc committee to determine what ISO will accept.

4.2  P1003.1 updates go international

WG15 is balloting to make 9945-1.2 (which corresponds to 1003.1a,
draft 5) a Draft International Standard (DIS). The TAG approved the
U.S. position with comments.  What's that mean?

Voting within WG15 is done by member country.  To arrive at the U.S.'s
position on a WG15 ballot, the TAG members draft a position then vote
on it, one vote per corporation.  (POSIX participation, in contrast,
is by individuals.) The final ballot resolution is presented to WG15
as the U.S. position, Sometimes a voice vote suffices, but DISs, NPs
(New Proposal, formerly New Work Item), or CDs (Committee Document,
formerly Draft Proposal), require a letter ballot.

The initial letter-ballot vote was nine yesses, two noes (with
comments), three abstentions; the two negative ballots were from Sun
and AT&T.  We considered three options for AT&T's comments:

  1.  do nothing and write a response to AT&T explaining why,

  2.  pass the comments on to WG15, or

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15


                - 4 -

  3.  pass the comments on to the 1003.1 working group, who could
      better judge their technical merits,

and chose the third.  In contrast, we incorporated Sun's comment into
our position.  Though someone suggested that AT&T might not be getting
fair treatment, Sun's comment (which simply noted that a change made
in chapter eight was not reflected in chapter two) was only a response
to the TAG ballot, while the AT&T comments, were more far-reaching
responses to 9945-1.2 itself and demanded a different forum.
Nevertheless, the group asked the ad hoc committee reforming TAG
procedures to reconsider the ballot resolution process.

4.3  How can you be two places at once (when you're ... )?

In light of the amount of time TAG meetings keep members from
attending working groups, we decided to meet Sundays before and
Thursdays and Fridays during the POSIX meetings.  This new schedule
will start with the Seattle meeting in October. The idea is to
complete as much as possible on Sunday and have Thursday and Friday
available if necessary. We agreed that the TAG should allocate this
much time to avoid one-day meetings like this one.  The SEC meeting
schedule may force this to change; several TAG members are TCOS
officers, committee chairs, or Institutional Representatives, all of
which are automatically SEC members.

4.4  Last, least

Both P1237 and X3T5.5 are working on remote procedure calls (RPC).
X3T5.5 is specifying the data stream encoding and P1237 is working on
the Application Programming Interface (API).  The TAG recommended that
the API work be brought to the ISO level under the WG15 umbrella.

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15

Volume-Number: Volume 20, Number 151

From [e-mail]  Wed Aug  1 20:47:26 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23336; Wed, 1 Aug 90 20:47:26 -0400
Posted-Date: 31 Jul 90 21:56:44 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07444; Wed, 1 Aug 90 13:45:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03123; Wed, 1 Aug 90 12:53:27 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Reply to utime() question
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 31 Jul 90 21:56:44 GMT
Apparently-To: [e-mail]

From:  [e-mail]

CEO document contents:

In article <[e-mail]> <uunet!samsung.com!audfax!arnold> writes:
>From:  [e-mail] (Arnold Robbins)
>
>Can someone with access to the 1003.1 standard tell me if the utime(2)
>system call is standardized, and if so if the definition of struct utimbuf
>is supposed to be in a particular header file?


>From POSIX 5.6.6.1:
       #include <sys/types.h>
       #include <utime.h>

       Int utime(path,times)
       char *path;
       struct utimebuf *times;

>From 5.6.6.2:
The utimbuf structure is defined by the header <utime.h>, and included the
following members:
       TYPE    NAME            Description
       time_t  actime          Access time
       time_t  modtime         Modification time

The 1990 revision of 1003.1 changes the definition to use an ANSI prototype:
       int utime(char *path, struct utimebuf *times);
and add the restriction the the utimebuf structure may not contain any members
other than the ones listed in the standard.

Note that utime() is the only function [I believe] where a structure is passed
into the system without having been obtained by a prior library call.  This
makes it "special".  I would guess that this is why AT&T never put it into a
header file.

                       --Donald Lewine
                       uunet!dg!lewine

Volume-Number: Volume 20, Number 153

From [e-mail]  Wed Aug  1 20:58:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28473; Wed, 1 Aug 90 20:58:44 -0400
Posted-Date: 31 Jul 90 21:59:37 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07426; Wed, 1 Aug 90 13:45:30 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03104; Wed, 1 Aug 90 12:52:40 cdt
From: Bob Lenk <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX Saved-Set-IDs v. System V
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 31 Jul 90 21:59:37 GMT
Apparently-To: [e-mail]

From:  Bob Lenk <[e-mail]>

In article <[e-mail]>,[e-mail] (John F. Haugh II) says:

> The conflict between 4.2.2.2 and System V setuid is that System V states
>
>     "If the effective user ID of the calling process is super-user,
>      the real user (group) ID and effective user (group) ID are set
>      to uid (gid)."
>
> and 4.2.2.2 states
>
>     "(1) If the process has appropriate privileges, the setuid()
>      function sets the real user ID, effective user ID, and the
>      saved set-user-ID to uid."

The behavior required in 4.2.2.2 is understood to be the actual behavior
of System V (at least Release 2, assuming that appropriate privilege
means super-user).

> The first problem is that a program which is set-user-ID to an ID other
> than super-user will behave quite differently when executed by root.

Correct.

> The second problem relates to processes which are set-user-ID to super-user.

Correct.

Contrary to the rationale, this behavior does not permit the application
to toggle between the real and saved set-user-ID unless both are not the
super-user's ID.

I'm not sure if this is contrary to the rationale, though it is more
complete.  The third paragraph of B.4.2.2 (top of page 236) explains
that the behavior for privileged processes is different.  The problem is
that setuid() and setgid() are overloaded with two behaviors, and the
behavior is selected by privilege (traditionally uid).  The fact that a
portable POSIX application has no way to determine whether it is
privileged makes this even worse.

> So, how does an application toggle between a non-super user and a super-user?

The only ways I know of are to use non-(POSIX/SysV) features or to use
two processes.  The current draft of the 1003.1a supplement (formerly
1003.1b, *not* the 1003.1-1990 revision) introduces the functions
seteuid() and setegid() to address this.

        Bob Lenk
        [e-mail]
        hplabs!hpfcla!rml


Volume-Number: Volume 20, Number 152

From jsq  Thu Aug  2 19:56:57 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA14505; Thu, 2 Aug 90 19:56:57 -0400
From: Guy Harris <auspex!guy>
Newsgroups: comp.std.unix
Subject: Re: POSIX Saved-Set-IDs v. System V
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 2 Aug 90 00:47:33 GMT
Apparently-To: std-unix-archive

From:  [e-mail] (Guy Harris)

>The rationale, in B.4.2.2, claims that this functionality is derived from
>System V

It is.

>and is designed to permit the application to toggle between the
>effective ID of the process and the real ID of the process creator.

It, like the S5 functionality it is derived from, does so as long as the
process isn't set-UID "root".  POSIX just inherits S5's deficiencies
here.

>The conflict between 4.2.2.2 and System V setuid is that System V states
>
>    "If the effective user ID of the calling process is super-user,
>     the real user (group) ID and effective user (group) ID are set
>     to uid (gid)."

That may be what the SVID *states* (or Issue 2 states, anyway; our copy
of volume 1 has disappeared), and is what the S5R3 documentation states,
but it ain't what System V *does*.  What System V *does* is:

>and 4.2.2.2 states
>
>    "(1) If the process has appropriate privileges, the setuid()
>     function sets the real user ID, effective user ID, and the
>     saved set-user-ID to uid."

...precisely that.  If you do "setuid(uid)" when the effective user ID
is super-user, the saved set-user ID, as well as the real and effective
UIDs, are set to "uid".

There's no conflict between what AT&T's S5 implementation does, and what
POSIX specifies.  There may be a conflict between what the SVID, Issue
2, specifies, and what POSIX specifies, but that means there's a
conflict between what the SVID, Issue 2, specifies and what System V
does, too.  (Remember, this is UNIX; the documentation isn't the
up-to-date spec for what the system does, the code is.)

In fact, the Third Edition of the SVID finally admits that; the wording
is the same as POSIX.  The S5R4 documentation also admits the way S5 has
worked since saved set-user IDs were first introduced.

>Contrary to the rationale, this behavior does not permit the application
>to toggle between the real and saved set-user-ID unless both are not the
>super-user's ID.  So, how does an application toggle between a non-super
>user and a super-user?

The author of the application lobbies one or more of POSIX and AT&T/UI
to specify or implement "seteuid()", a call that takes one argument and
sets the effective user ID, and *ONLY* the effective user ID, to the
value of that argument, even if the process has appropriate privileges.
Without a call like that - which some systems with saved set-user IDs,
such as SunOS 4.x, have, and which System V Release 4 may even have, but
without documentation - you're screwed.


Volume-Number: Volume 20, Number 154

From jsq  Thu Aug  2 19:57:48 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA14893; Thu, 2 Aug 90 19:57:48 -0400
From: Ron Heiby <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Motorola Microcomputer, Schaumburg, IL
Date: 1 Aug 90 16:55:34 GMT
Apparently-To: std-unix-archive

From:  [e-mail] (Ron Heiby)

My understanding is that not only has the utimbuf structure been
standardized and included in sys/utime.h, but it was changed in
a manner incompatible with current practice.  Since the beginning
of time, the structure has been documented as being a pair of
time_t values (usually longs), the first specifying the access
time and the second specifying the modification time.  Now, it's
been defined to be four time_t values.  The additional two are
for additional microseconds beyond the existing time in seconds.
Do you think maybe the two new values could be put at the end
of the structure where they would do little harm?  No way!  Where
the modification time value *used* to be, now we find microseconds
tacked onto the access time value.  Also, since there was never
before a header file for utimbuf, everyone who uses it has it hard
coded into their own code (or their own .h file, if they're lucky).
The thing that really gripes me about this is that I haven't found
anyone who can explain to me why the access and modification times
for a file have to be settable to the microsecond.  It's simply
ridiculous!
--
Ron Heiby, [e-mail]    Moderator: comp.newprod
"Mandatory Drug Testing?  Just Say NO!!!"

Volume-Number: Volume 20, Number 155

From [e-mail]  Thu Aug  2 18:08:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27668; Thu, 2 Aug 90 18:08:34 -0400
Posted-Date: 2 Aug 90 16:12:49 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA03781; Thu, 2 Aug 90 14:55:38 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05294; Thu, 2 Aug 90 14:50:07 cdt
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: End of comp.std.unix Volume 20
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 2 Aug 90 16:12:49 GMT
Apparently-To: [e-mail]

From: [e-mail] (Moderator, John Quarterman)

This is the last article in Volume 20 of the newsgroup comp.std.unix
and the mailing list [e-mail].  Volume 21 will start today.

These volumes are purely for administrative convenience.  Please feel
free to continue any previous discussion and to start any new ones.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 20, Number 156