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

Internet Message Format | 1991-11-17 | 364KB

From: Sean Eric Fagan <[e-mail]>
Subject: Policy and Guidelines for comp.std.unix
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 3 Sep 1991 16:54:34 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

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

This is Volume 25 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 U.S. and other Technical Advisory Groups (TAGs) to WG15,
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba, GNU,
    and the USENIX Standards Watchdog Committee.

Moderator.

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

Disclaimer.

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

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


Postings.

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

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

In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or cygnus.com (e.g., [e-mail]).  If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.
Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

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

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

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

Archives.

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

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

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

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

The output of "cd ~ftp/usenet/comp.std.unix; ls -l" is in
        ~ftp/usenet/comp.std.unix/list
and the output of "cd ~ftp/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.

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

The previous moderator claimed a 90% acceptance rate; 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.  If a message
appears to be directed towards me, I will reply; if I am unsure, I wil ask
the sender if posting is really necessary or desired.

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

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

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



Editorial policy.

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

Headers and trailers

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

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

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.

Also, signatures that are excessively long may be truncated.



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 usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possesive or
``its'' as a contraction of ``it is'' are corrected.

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 about every other month in four articles with these titles:
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The first three are posted to
    comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.

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

USENIX Standards Watchdog Reports

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

EUUG/USENIX ISO Monitor Project

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

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

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

Volume-Number: Volume 25, Number 1

From [e-mail]  Wed Sep  4 15:58:16 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19300; Wed, 4 Sep 91 15:58:16 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14832; Wed, 4 Sep 91 15:58:14 -0400
Newsgroups: comp.std.unix
From: Brian Matthews <polari!6sigma2>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Seattle Online Public Unix [phone]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Sep 1991 17:25:06 GMT
Reply-To: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
|Instead of selecting one arbitrarily, it
|would make more sense to allow it to fit the system characteristics
|(i.e., use the system's minimum disk block size, which could be any
|positive size, and typically is either 512B or 4096B)

Gak.  Over the course of any random month I work on perhaps ten different
"UNIX" systems.  I have absolutely no idea what the "system's minimum
disk block size" is, and in many cases the people owning the computer
don't know either.  I suppose I could write a little test program that
wrote various sized files and exec'd du's to figure out what size
blocks du is using, but should I have to?

|or to allow the
|user to scale the units according to his own needs.

Whatever happens, this is a necessity.  Luckily, GNU du already allows
this.
--
Brian L. Matthews    [e-mail]


Volume-Number: Volume 25, Number 2

From [e-mail]  Wed Sep  4 15:58:25 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19370; Wed, 4 Sep 91 15:58:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14854; Wed, 4 Sep 91 15:58:22 -0400
Newsgroups: comp.std.unix
From: Donn Terry <[e-mail]>
Subject: Re: POSIX.1 stream functions
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 3 Sep 1991 23:43:44 GMT
Reply-To: [e-mail]
To: [e-mail]

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

>I have POSIX 1003.1-1988 and 1990 in front of me.
>Section 8.2.3 (Interaction with C stream functions) has some major changes.

>Why was the requirement that fclose() set the file descriptor offset
>to the stream offset removed? Note the 1990 rational is wrong.
>This means applications have to do it themselves with
>    fflush(fp);
>    fseek(fp, 0L, SEEK_CUR);

>I understand why fflush is no longer required to invalidate input buffers,
>but is a 1990 implementation required to leave input buffers untouched
>on non-seekable files? For example, can I write
>    fgetc(stdin);        /* first byte */
>    fflush(stdin);
>    [fork(), child does not use stdin but does exit()]
>    fgetc(stdin);        /* second byte */
>without concern that stdin may be a pipe?
>Or do I have to conditionalize the fflush with
>    if (!seekable(fileno(stdin))
>If so, how can I write seekable(), allowing for implementations
>that have non-seekable devices other that ttys and pipes?

>Or, when using fork(), is it required to use _exit() and explicit fflush()s?

>        Eric Gisin, [e-mail]


Speaking for myself (but with a LOT of insight into the -1990 balloting
process :-) ):  the wording in the -1988 standard was weak, and it was
possible (actually probable) that some system vendors would misread it.

At least one did, and consequently created a ballot objection that
claimed that it was impossible to implement the requirement in -1988
correctly.  At the time, it was necessary to remove the requirement to
remove the balloting objection, and since it was supported by a
prestigeous body, it could not be ignored.  (Yes, I intended not to use
any names in that sentence!)

At least one vendor has implemented the intended semantics, and it does
work completely transparently to existing applications, including use
in all AT&T-provided commands.

-1990 was written to permit the intended correct operation, and to require
vendors to tell you whether it does or not (see the "implementation-defined").
The 1003.1a revision restores the previous intent, and contains much clearer
wording, and some detailed rationale about how to implement it.
(Whether that will pass standardization remains to be seen.)


Donn Terry

Speaking only for myself, but with a certain amount of experience as
1003.1 chair.

Volume-Number: Volume 25, Number 4

From [e-mail]  Wed Sep  4 15:58:26 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19381; Wed, 4 Sep 91 15:58:26 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14862; Wed, 4 Sep 91 15:58:24 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Sep 1991 18:07:48 GMT
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> Your STRAW MAN argument about allocating individual bits would perhaps
> be "silly", but I did not make that argument.  I did note that not all
> file sizes (expressed as number of bits) are exactly divisible by 8,
> which would make the 8-bit byte rather a silly unit of measure.  And
> other-size bytes more appropriate for such systems aren't necessarily
> any more useful.  While a 9-bit byte may be ideal for an 18-bit system,
> what would you use on a 60-bit system?

Blue sky time...

I would say it would be desirable to get the size in all the following units:

    bits
    characters (yes, that may mean 16 or 32 bit charactars under
            Unicode or ISO10646)
    integers (16-, 18-, 32-, 36-, or 60 bit chunks)
    floats (32-, 36-, 48-, 60-, 96-, and so on bit chunks)
    words (minimal unit of memory storage)
    blocks (minimum unit of storage allocation)

There should also be a program to convert between these units:

    units [from [to]]

Back to reality...

> I don't think there is a large advantage to using bit sizing, although
> it does permit CORRECT, PRECISE information to be given in all cases.

That depends. It doesn't tell you how many pages of your book can be stored
in that space. You need to know how many bits per character for the file
system and hardware in question. This may be a hard question to answer if
you just remote-mounted a Unisys file system containing both ASCII and
Fielddata elements.

Practically, how many systems out there still use non-octet-oriented memory?
The Unisys 1100 series is the last that I can think of, and they don't
support UNIX.

> However, the argument that 1024 8-bit bytes is somehow an optimum unit
> of measurement for file sizes needs to be shot down.  It's just one of
> many possible arbitrary choices.

It's no worse than any other, and has the advantage that it's meaningful
to most people. People expect file sizes to be expressed in kilobytes, on
both SysV and BSD. I use SysV myself, and I wish I didn't have to divide
displayed sizes by a factor of 2 all the time.

Sure, that means you may be inaccurate in some cases, and underestimate the
storage available.
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  [phone]
"Have you hugged your wolf today?"



Volume-Number: Volume 25, Number 3

From [e-mail]  Wed Sep  4 15:58:31 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19420; Wed, 4 Sep 91 15:58:31 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14888; Wed, 4 Sep 91 15:58:28 -0400
Newsgroups: comp.std.unix
From: Donn Terry <[e-mail]>
Subject: Re: Voting
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 4 Sep 1991 00:03:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

I wanted to observe that although the "voting" results may be more-or-less
accurate, I have some concerns about the accuracy of the population that
is doing the voting.

The set of people reached on the net is a rather small subset of the
really serious UNIX users, in that it omits all the non-connected systems,
and many of the connected systems do not include people who would read
this notes group, who would respond (or in some cases would be allowed
to respond).

Since several manufacturers sell systems which claim conformance to the
SVID, and many of these systems are small systems which are probably
not connected, the "current usage" set of people is improperly represented.
(I refer specifically to SCO's product and to vendors like (the old) NCR.)

My guess is that over half of the current UNIX population uses systems
which use 512 byte blocks, and they *might* be chagrined to find that POSIX
had "fixed" the problem for them.

I distrust the "voting" as rather poor sample of the actual population.


My personal opinion on the technological issue is completely distinct from
the observation made above.  (And it may or may not favor 512 byte blocks.)

Donn Terry


P.S.  Any whining about not being able to participate in the POSIX process
is simply explicit proof of ignorance.   The process is completely open,
and anyone can participate by simply taking the time to do so.

(IEEE or Computer Society membership gives your vote more "clout", but
it's not very expensive and there are a lot of benefits beyond the extra
clout.  However, no opinion can be simply, out of hand, ignored because
it does not come from and IEEE member.  Not only does IEEE audit that
(well above the "POSIX" level, but ANSI re-audits it!)  (Copies of the
document aren't free, but somebody has to pay for the copying; it's not
free either.)


Volume-Number: Volume 25, Number 2

From [e-mail]  Wed Sep  4 15:58:36 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19445; Wed, 4 Sep 91 15:58:36 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14928; Wed, 4 Sep 91 15:58:33 -0400
Newsgroups: comp.std.unix
From: Donn Terry <[e-mail]>
Subject: Re: "voting"
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 4 Sep 1991 00:03:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

I wanted to observe that although the "voting" results may be more-or-less
accurate, I have some concerns about the accuracy of the population that
is doing the voting.

The set of people reached on the net is a rather small subset of the
really serious UNIX users, in that it omits all the non-connected systems,
and many of the connected systems do not include people who would read
this notes group, who would respond (or in some cases would be allowed
to respond).

Since several manufacturers sell systems which claim conformance to the
SVID, and many of these systems are small systems which are probably
not connected, the "current usage" set of people is improperly represented.
(I refer specifically to SCO's product and to vendors like (the old) NCR.)

My guess is that over half of the current UNIX population uses systems
which use 512 byte blocks, and they *might* be chagrined to find that POSIX
had "fixed" the problem for them.

I distrust the "voting" as rather poor sample of the actual population.


My personal opinion on the technological issue is completely distinct from
the observation made above.  (And it may or may not favor 512 byte blocks.)

Donn Terry


P.S.  Any whining about not being able to participate in the POSIX process
is simply explicit proof of ignorance.   The process is completely open,
and anyone can participate by simply taking the time to do so.

(IEEE or Computer Society membership gives your vote more "clout", but
it's not very expensive and there are a lot of benefits beyond the extra
clout.  However, no opinion can be simply, out of hand, ignored because
it does not come from and IEEE member.  Not only does IEEE audit that
(well above the "POSIX" level, but ANSI re-audits it!)  (Copies of the
document aren't free, but somebody has to pay for the copying; it's not
free either.)


Volume-Number: Volume 25, Number 5

From [e-mail]  Wed Sep  4 15:58:41 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19512; Wed, 4 Sep 91 15:58:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14990; Wed, 4 Sep 91 15:58:39 -0400
Newsgroups: comp.std.unix
From: Rahul Dhesi <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Cirrus Logic Inc.
References: <[e-mail]> <[e-mail]>
Date: Wed, 4 Sep 1991 01:02:41 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rahul Dhesi)

Most people don't much care about "blocks" and "block size", except
when they happen to be writing tapes.  They are usually interested more
in the slightly different concept of "disk space" when they use
utilities such as "du" and "df".

What units should be used when reporting disk space?  Kilobytes and
megabytes come to mind immediately as likely possibilities.  Units of
512 bytes do not.

I assume that the original purpose of reporting disk space in blocks
was that doing so allows for disk space wasted due to fragmentation.
But block size can vary from filesystem to filesystem, and filesystem
organization may be more complex than a single block size can describe
(e.g., consider fragments in the BSD filesystem).

Therefore "df" and "du" should simply report disk space in kilobytes
and avoid picking any block size at all.

--
Rahul Dhesi <[e-mail]>
UUCP:  oliveb!cirrusl!dhesi
"You're even nuttier than we've come to expect of you." -- Doug Gwyn


Volume-Number: Volume 25, Number 6

From [e-mail]  Wed Sep  4 15:58:47 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA19533; Wed, 4 Sep 91 15:58:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15028; Wed, 4 Sep 91 15:58:44 -0400
Newsgroups: comp.std.unix
From: Stefan Esser <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Institute of Nuclear Physics, University of Cologne, Germany
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Tue, 3 Sep 1991 17:48:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Stefan Esser)

In article <[e-mail]>, [e-mail] (Doug Gwyn) writes:

|> If a single size is nonetheless selected for the standard, it must
|> make technical sense -- since many important systems allocate files
|> in integral (perhaps odd) multiples of 512B, and those units can be
|> used to correctly and accurately express sizes of files on systems
|> that allocate in integral multiples of 1024B, while the reverse is
|> NOT TRUE, obviously 512B would be better than 1024B for a standard
|> that must accommodate both kinds of systems.  But flexibility would
|> be better yet.
There's a 'zoo' of UNIX systems in this institute, but *none* of them is
capable of allocating a single 512 byte sector for a file !
All our BSD FFS are configured as 8k/1k (or 8k/8k) blocksize/fragmsize.
The one lonely left over Sys.V system (a Compaq 386/25 running 386/ix)
has a file system based on 1k blocks for years now ...
Are there really many systems allocating 512 bytes at a time, to be
expected in the future ?
In my opinion they are nearly gone, today ...
Why take the ballast of an arbitrary unit of file size (block), if you already
have one 'portable' unit (Byte) that is widely understood ?

|> I must say that attempts to force "solutions" based on popularity
|> polls rather than careful reasoning about the actual relevant
|> factors is disgusting.  Demagogues would do us all a favor by staying
|> out of the standardization process.
I think careful reasoning will show, that there is a big number of systems
with 'du' and 'df' showing KB for years now, and that either we invent
a way to control the behaviour (how about an environment variable :-)
that is required by the standard, or we choose one of the ways in which
du/df are behaving now and make this the standard.
Being the sysadmin of a network of Suns, DECs, HPs and 386s (MACH
and Sys V.3) I know what I'd prefer ...
[The bad thing in HP-UX is, that 'df' is the Sys.V one (showing blocks).
 The good thing is, that bdf is the BSD 'df' showing KB.
 Guess which one is being used (aliased to 'df' :-) here ... ]

Its true, that not every number 512 byte blocks can be expressed as an
integral number of KB, but since I'm mostly looking for sizes of directory
trees when using 'du' and its acceptable to be 512Byte off for a large
directory, that really (IMHO) doesn't matter.
If I were going to sum up all this subdirectory sizes and expecting to end
at the disk size, I might be disappointed, but I'm usually not counting
blocks to be sure none has been lost ...

|.            Demagogues would do us all a favor by staying
|> out of the standardization process.
Yes, that seems a reasonable idea.
But didn't your comment sound a bit demagogic as well ?

Stefan Esser
--
 Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
 [e-mail]                                           [134.95.192.50]


Volume-Number: Volume 25, Number 7

From [e-mail]  Wed Sep  4 16:09:54 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA23777; Wed, 4 Sep 91 16:09:54 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18449; Wed, 4 Sep 91 16:09:53 -0400
Control: cancel <[e-mail]>
Newsgroups: comp.std.unix.ctl
From: Sean Eric Fagan <[e-mail]>
Subject: Re: Voting
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Date: Wed, 04 Sep 1991 20:03:01 GMT
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.
Apparently-To: <[e-mail]>

This one got out by accident, so I'm cancelling it.  I'm also
[e-mail].

--
Sean Eric Fagan  | "Never irritate someone in charge
[e-mail]  |       of  another dimension."
-----------------+              -- Rod Darian
Any opinions expressed are my own, and generally unpopular with others.

From [e-mail]  Wed Sep  4 16:12:30 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA24707; Wed, 4 Sep 91 16:12:30 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19068; Wed, 4 Sep 91 16:12:27 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Wed, 4 Sep 1991 17:41:08 GMT
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Tony L Hansen) writes:
> "A block is a block is a block" and "A block consists of 512 bytes".

We're running Xenix, UNIX System V, BSD UNIX, MS-DOS, and VAX/VMS. And our
UNIX tools can see all of them.

I have some tools that talk in 512 byte blocks, some in 1K blocks, and some
look at the file system and use its block size. I have file systems with 1K
blocks, 512 byte blocks, and 2K blocks. I have file systems with file
granularity varying from 256 bytes up to 8K. Currently, one "du" I use
reports in 1K blocks, one in 512 byte blocks. I have a "df" that reports in
1K always, one that looks at the file system, and one that falls back on
"bytes".

A block isn't always a block, and even when it is it's rarely 512 bytes.

At least a byte is always 8 bits: our mainframes don't support RFS or NFS. If
they did, we'd have to deal with some weird block size... some non-power-of-2
multiple of 36 bit words, with either 4 9-bit characters or 6 6-bit characters
in each word...

    (Sperry and Burroughs: you take 36 bit computers, and 48 bit
     computers, and mix them together... so why is their slogan
     "Unisys: the power of 2"?)

> >Which of these two alternatives would you prefer, and how much?
> >* df and du output is in units of 1024.
> >* df and du is in units of 512 unless you use -k.

df and du in "bytes" or "1k blocks", preferably switchable.
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  [phone]
"Have you hugged your wolf today?"



Volume-Number: Volume 25, Number 8

From [e-mail]  Wed Sep  4 16:12:34 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA24745; Wed, 4 Sep 91 16:12:34 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19092; Wed, 4 Sep 91 16:12:30 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Sep 1991 17:48:43 GMT
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Richard A. O'Keefe) writes:
>     BLOCK_UNIT=1        # for me
>     BLOCK_UNIT=512        # for 512ists
>     BLOCK_UNIT=1024        # for 1024ists
>     # no assignment        # for people who want POSIX behaviour

My god, a rational, intelligent solution. Someone shoot this man, he's
obviously dangerous.

> Ideally, that would be ``locale''-specific.  A simple approach would just be
> to display
> Filesystem          size/512    used   avail capacity  Mounted on

Ack, no. Dump it out in a format that can be parsed! There are too many DF
format as is, anyway, but there's no point in having a header in there...

/xxx    (/dev/dsk/whatever)    9999 K    9999 inodes

> Of course, the Right Answer is that 'df' should be a relation, not a
> program, and df itself should be a trivial AWK script on top of that.

Or at least a program that dumps a relation:

/xxx:/dev/dsk/whatever:3000000:999000:9999
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  [phone]
"Have you hugged your wolf today?"

[ I think this subject is about beaten to death.  Unless you have something
  new to say, please refrain from feuling the fire.  Thanks -- mod ]

Volume-Number: Volume 25, Number 9

From [e-mail]  Wed Sep  4 16:12:40 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA24817; Wed, 4 Sep 91 16:12:40 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19121; Wed, 4 Sep 91 16:12:34 -0400
Newsgroups: comp.std.unix
From: Karl Heuer <[e-mail]>
Subject: Error detection
Message-Id: <[e-mail]>
Summary: Must a POSIX implementation detect wrong-direction I/O attempts?
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Wed, 4 Sep 1991 20:06:08 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Karl Heuer)

A certain vendor's test suite for POSIX compliance expects that code like
    fp=fopen(fname, "w"); c=getc(fp); /* attempted read from output stream */
must cause a run-time error (EBADF, I think).  I claim that the behavior is
undefined.  Who's right?

The reason this is an issue, is that the common AT&T implementation of
getc() as a macro doesn't always catch this error.  It merely extracts a
byte from the buffer, and doesn't notice that it's dealing with an output
buffer rather than an input buffer.  Our implementation currently follows
AT&T's, and it is failing the test suite.

The person in charge of fixing this problem wants to make getc() a function
call instead of a macro, and add the additional check on each call.  I
believe that if we follow this route, we'll end up with an implementation
that passes the test suite but that nobody wants to use.

My own preference, of course, is that the test suite be ruled incorrect.  If
in fact POSIX does require this error to be detected, or if it turns out to
be politically infeasible to ignore the error, or if user demand suggests
that the feature would be useful anyway, then I would prefer a solution that
fixes the problem without affecting the efficiency of getc().  For example,
we could reimplement the FILE structure to have separate _icnt and _ocnt
variables.  However, this solution may have its own semi-political problems,
if we're committed to following an ABI that spells out the shape of the FILE
structure.

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



Volume-Number: Volume 25, Number 10

From rbj  Wed Sep  4 19:41:04 1991
Received: by uunet.uu.net (5.61/UUNET-uucp-primary)
    id AA04132; Wed, 4 Sep 91 19:41:04 -0400
Date: Wed, 4 Sep 91 19:41:04 -0400
From: rbj (Root Boy Jim)
Message-Id: <[e-mail]>
To: std-unix-archive
Subject: TEST

IGNORE

From rbj  Wed Sep  4 19:43:41 1991
Received: by uunet.uu.net (5.61/UUNET-uucp-primary)
    id AA04957; Wed, 4 Sep 91 19:43:41 -0400
Date: Wed, 4 Sep 91 19:43:41 -0400
From: rbj (Root Boy Jim)
Message-Id: <[e-mail]>
To: std-unix-archive
Subject: TESTING

IGNORING

From [e-mail]  Fri Sep  6 14:50:46 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA01979; Fri, 6 Sep 91 14:50:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03084; Fri, 6 Sep 91 14:50:39 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, Editorial
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

The Five Great Myths of Open Systems Standards
USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor


I recently read a column where the author described computer people at
cocktail parties as the doctors of the 90's.  Instead of everyone
wanting to discuss their aches and pains with some poor medical
practitioner while they're trying to sip scotch and nibble hors
d'oeuvres, computer people are plagued with the latest chat from
computer literate business people.

No longer are you merely cornered by DOS know-it-alls, now you get to
deal with the sweeping issues of GUI Wars, and whether UNIX will
displace DOS on the desktop. Open systems are in vogue. Standards are
``sexy''.

With all of this comes the new ``Open Systems'' know-it-all.  These
are people who can spell POSIX, but can't pronounce it. They've all
been taken to lunch recently by their favourite marketing rep from one
of those lavish companies whose name is a regulation three letter
acronym, let's call them TLA for short.

I started discerning certain patterns in all of this idle gossip and
chatter, and now present to you the Five Great Myths of Open Systems
Standards:

Myth #1

``Vendor TLA IS the standard.'' This is the traditional mix-up between
de jure standards, and de facto standards. Or REAL standards and
market share. De jure standards are built by accredited standards
development bodies. There is a fair process involved to ensure all
points of view are heard. It is a consensus process, not a majority
one.

De facto standards are mostly under the limited control of a single
organization.  They are often trade marked. If they are available at
all outside of their controlling organization, the technology is often
licensed. The holder of the license effectively controls where they
want to take the technology. They accept input from some form of user
constituency, but ultimately they run the show. I look at this as the
difference between a POSIX standard interface, and a UNIX operating
system.

Myth #2

``Vendor TLA is part of the standards development group, and they're
donating this technology to the standard.'' Always a knee slapper. As
if all it took to make a standard was for a vendor to donate part of
its technology, obviously out of the goodness of its heart for
mankind. These people have not participated in the excitement of a
Threads Wars, or the current painful GUI Wars.

Many vendors would love to have their specification as a standard.  It
gives them an instant product to sell into the hot ``standards''
market. They just have to get past the rest of the standards working
group, made up of various backgrounds and biases.

Then comes a balloting group, a superset of the working group. These
people haven't necessarily had the benefit of participating in the
discussions that led to a decision. The popularity of publishing the
rationale for decisions helps alleviate this problem, but not always.
There will always be people in a balloting group that know their
solution is the technically correct one. It's a whole lot easier to
disagree with the committee, balloting a draft you didn't help make,
than in the working group sessions where the talking is done face to
face.

Other vendors don't want their technology to be a public controlled
standard.  They lose control of their own specification. If they have
a large market share, i.e.  they're a de facto standard, they may want
nothing to do with becoming a de jure standard.

Myth #3

``Vendor TLA sells a POSIX conforming system.'' Wrong. No one sells a
``POSIX'' conforming system. Indeed, POSIX conformance is the real
myth here.

POSIX.3 is a standard which defines the test methodology used to
measure conformance to POSIX. It has recently become a standard, IEEE
1003.3-1991. An accompanying document, still in the balloting process
and therefore unstable, is POSIX.3.1. This document contains the test
methods themselves for POSIX.1, (the base system interface standard),
which everyone refers to as ``POSIX''.

By definition, POSIX.3.1 is not yet a standard, hence no POSIX.1
conformance test suite actually exists.

There is a United States government procurement profile of POSIX.1
called FIPS 151-1, or in today's open systems circus, simply ``THE
FIPS.'' FIPS 151-1 chooses certain options within the standard.  It
even defines certain behaviour that in the standard is left as
implementation defined. It was written against the original POSIX.1
standard, IEEE 1003.1-1988, not the current one, (IEEE 1003.1-1990.)
In fact it was written prior to the completion of the standard.

In theory, nothing changed in POSIX.1, between 1988 and 1990, except
for the reformatting to make it ISO acceptable, and ``bug fixes''.
The removal of cuserid() was a ``bug fix''.

Because of the obvious buying power of the U.S. government, most major
vendors are implementing FIPS 151-1. It is a profile or subset of
POSIX.1.

Test suites exist to test conformance against FIPS 151-1.  These must
use the test methods described in POSIX.3.1 (still in ballot.) One of
them was written to an early draft of POSIX.3.1.  Another was written
by using the AT&T UNIX System V Verification Suite (SVVS) as a base.
SVVS dependencies are still being discovered and weeded out of this
one. It is quite possible to implement something different from the
FIPS, which would fail the FIPS test suites miserably, yet would
technically conform to the standard.  (If only there was a way to
prove it.)

Myth #4

``POSIX isn't important - it's source code portability that's
important.'' Well, no and yes. One vendor is notorious for this game.

Yes, absolutely, source code portability is what it's all about. This
is typically one of the banners that's waved around in many people's
definitions of open systems.

POSIX is a family of standards designed to provide source code
portability. The interface was derived from the many UNIX system
interfaces that existed. UNIX was/is a de facto operating system in
many arenas. Many vendors are implementing the POSIX interface on
their non-UNIX derivative proprietary operating systems.

No, POSIX is not UNIX. Many UNIX developers mourn and despise what has
happened to the UNIX interface. They shouldn't. First of all, the base
technology, which is close enough that they are already familiar with
it, is becoming available on a huge installed base of technology. The
demand will far outstrip the supply of technologists familiar with it.
Second, nothing is preventing them from continuing on in their current
preferred environment. It is different enough that they can continue
developing software as they always have. It's just not as portable.

There are other software development environments which ensure
software portability. VMS on a VAX architecture guarantees portability
of source (and executables) across the entire line of VAX hardware.
This is fine if that's where your business lays.  Likewise, IBM's SAA
will provide similar source portability benefits across disparate IBM
architectures. They're really muddying the waters by also implementing
some of the other ``open system'' interfaces on the SAA platforms.
Again, it all depends where you as a software developer want to draw
the portability line. POSIX is becoming the path to widest portability.

Myth #5

``Open systems technologies will revolutionize the way software is
developed.'' Yet another silver bullet contestant.  Everyone remember
the marketing hype around 4GLs? CASE? These are all good useful
technologies. They simply need to be applied in their proper forum.
They do not remove the responsibility of thought, i.e. creative
design, careful development, and inventive testing of a problem's
solution.

The current ``promise'' of open systems technologies has us living in
a completely networked corporation of resources.  Applications running
where the optimal appropriate processing resource is.  Information
available everywhere at once, both properly protected and with its
true location completely irrelevant. All of it interfaced via some
wonderful intuitive graphic user interface.

I do believe this is where we're going. The technology is often
commercially available already, but with some very real constraints on
it. Often these constraints involve how new the technology is, and the
lack of standardization.

It is a great vision, but before it's available in completely
heterogeneous networked environments, the technology has to stabilize
enough for standards to be created. No matter how dazzling the
technology seems to be, a standard cannot be wrestled on to it too
early, or it becomes a straight jacket on the creative forces shaping
it.

Networked system administration at this level is in its infancy. A
corporation's information and application architecture is often
weighted down in a heavy history of legacy systems.  (That's if the
corporation can even draw its architectures!) These are a couple of
the ``minor'' problems that need to be dealt with before marketing
sells the ``promise'' too fully.

Conclusions

So there they are. My five favourite myths of open systems standards.
I'm sure this is just the beginning. (I don't get to a lot of cocktail
parties. I have small children.)

I'd love to hear other additions to this. No matter how outrageous.

Volume-Number: Volume 25, Number 11

From [e-mail]  Fri Sep  6 14:50:55 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02038; Fri, 6 Sep 91 14:50:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03110; Fri, 6 Sep 91 14:50:45 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.0: Guide to Open Systems Environments
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.0: Guide to Open Systems Environments


Kevin Lewis <[e-mail]> reports on the July 8-12, 1991
meeting in Santa Clara, CA:

The July meeting of POSIX.0 saw a different approach to the week's
work.  Instead of abiding by the draft agenda, the group trashed it
and took what might be called a ``fish or cut bait'' approach.
POSIX.0 looked at each major section and determined whether or not it
was ready for mock ballot, or could be made ready by the October
meeting.

Accomplishing the latter required individuals to step up to the task
of editting sections during the meeting, with some degree of plenary
review before the week's end.  This required a commitment from the
group at large to refrain from any super ethereal or journalistically
based editorial discussions. This has sometimes been hard to avoid in
the past.  The group stuck to its guns, however, and a great deal of
headway was made.

The sections within the guide that remain undecided for mock ballot
are:

   - networking,

   - security,

   - graphics (GKS, etc.),

   - command user interface,

   - system administration,

   - fault management.

Should the group decide that a section is not ready, we will simply
not include it in the mock ballot. It will be included in the formal
ballot.

As it currently stands, the group plans to start the mock ballot early
in November, bringing all ballot comments to the January meeting.
This appears to be very feasible.

The POSIX.0 project was reviewed at this meeting by the TCOS-SS
Project Management Committee.  The review determined there was the
need for other TCOS-SS working groups to better coordinate with and
contribute to the POSIX.0 guide.

This was mandated through an SEC resolution.  The greatest concern
among the other standards working groups is ``how in the world are
they going to find time to do that.'' The groups are already concerned
about their current work loads.

I believe that once we go through the preparation at the October
meeting, and get into the mock ballot, many of the loops that are
still open will be closed.  That is not to say that there will be no
outstanding issues, but the major concerns should be laid to rest.

Volume-Number: Volume 25, Number 12

From [e-mail]  Fri Sep  6 14:51:05 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02146; Fri, 6 Sep 91 14:51:05 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03155; Fri, 6 Sep 91 14:50:57 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.3: POSIX Test Methods and Conformance
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.3: POSIX Test Methods and Conformance

Andrew Twigger <[e-mail]> reports on the July 8-12, 1991 meeting
in Santa Clara, CA:

The Santa Clara meeting could in many ways be considered to be one of
the less eventful of the recent POSIX.3 meetings.

Draft 5 of the POSIX.3.2 document was distributed at the meeting, with
the majority of the test assertions having been aligned with the text
of POSIX.2 (Shell and Utilities) Draft 11.  This alignment was
exquisitely timed to coincide with the production of Draft 11.1 of
POSIX.2, immediately rendering parts of Draft 5 out of date!  Perhaps
the documents can be synchronized for the next meeting, or the one
after that, or ....

The majority of the POSIX.3 working group spent most of the meeting
writing assertions with POSIX.2.  Having already dealt with the
``simpler'' utilities, some of the more complex utilities (make, pax,
ls) were tackled during the week.  The next draft should contain
assertions for about 95% of the utilities, however the remaining 5%
could take 95% of the time!

The ballot review group for POSIX.3.1 met briefly during the week to
look over the objections received during the last ballot
recirculation.  Most of these had been resolved prior to the meeting
and it was expected that the remaining items could be resolved by the
end of August.  Another brief recirculation ballot is expected in the
Autumn, with possibly another standard being completed by the end of
the year.

The SCCT met twice during the week and finally approved some of the
test method development plans submitted by the other working groups.
The rumour that this was only in response to moans from the other
working groups that the SCCT had rejected every plan submitted in the
previous nine months is not entirely without foundation!  Most of the
other working groups, however, are getting geared up to produce test
methods with their documents.

Several members of POSIX.3 spent time in assisting other working
groups to develop test methods for their standards.  Much of this time
was spent in helping the working groups to understand how significant
a task this is and in helping the working groups to develop a
reasonable strategy for test methods.  Some time was also spent in
reviewing the work that had already been done by work group members.
There seems to be an increased awareness of the problems and an ever
improving quality to the test methods that the working group are
producing.

Volume-Number: Volume 25, Number 14

From [e-mail]  Fri Sep  6 14:51:03 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02129; Fri, 6 Sep 91 14:51:03 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03128; Fri, 6 Sep 91 14:50:50 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.2: Shell and Utilities
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen Walli <[e-mail]>, Report Editor
Report on POSIX.2: Shell and Utilities


David Rowley <[e-mail]> reports on the July 8-12
meeting in Santa Clara, CA:

Summary

POSIX.2 (Shell and Utilities) Draft 11.1 closed its recirculation
ballot on July 19. This draft was circulated as the 250 pages that had
changed from Draft 11. Balloting a ``changes-only'' draft proved to be
a challenge in itself.  POSIX.2a (User portability extension) Draft 7
closed its recirculation ballot on August 19.

POSIX.2b has been approved after a number of recommendations from the
Project Management Committee.  The POSIX.2 group continued work on the
new PAX archive format.  Most of the time was again spent in a joint
meeting with POSIX.3.2 (Test Methods for POSIX.2) creating test
assertions for the document.

Background

A brief POSIX.2 project description:

   - POSIX.2 is the base standard dealing with the basic shell
     programming language and a set of utilities required for the
     portability of shell scripts.  It excludes most features that
     might be considered interactive.  POSIX.2 also standardizes
     command-line and function interfaces related to certain POSIX.2
     utilities (e.g., popen(), regular expressions, etc.).  This part
     of POSIX.2, which was developed first, is sometimes known as
     ``Dot 2 Classic.''

   - POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base standard. It standardizes commands, such as vi, that
     might not appear in shell scripts, but are important enough that
     users must learn them on any real system.  It is essentially an
     interactive standard, and will eventually be an optional chapter
     to a future draft of the base document.  This approach allows the
     adoption of the UPE to trail Dot 2 Classic without delaying it.

     Some utilities have both interactive and non-interactive
     features.  In such cases, the UPE defines extensions from the
     base POSIX.2 utility.  Features used both interactively and in
     scripts tend to be defined in the base standard.

   - POSIX.2b is a newly approved project which will cover extensions
     and new requests from other groups, such as utilities for the
     POSIX.4 (Realtime) and POSIX.6 (Security) documents.

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

POSIX.2 Status

Resolution of POSIX.2 Draft 11 ballot objections was completed, and a
Draft 11.1 was re-circulated. There were 900 objections received for
Draft 11.  The Draft 11.1 recirculation ballot closed July 19.

This draft was circulated as a 250 page ``changes-only'' document.
This is created by printing the document and extracting all those
pages containing change bars. Although this saves paper, it makes
balloting extremely difficult.  The context of the changes is lost.
Since the page numbers (and even some section numbers) have changed
since Draft 11, cross referencing old drafts doesn't help much.

The intent of this technique is to physically demonstrate the increase
in consensus by the smaller size of the document. Even though
balloting is made more difficult, I agree with the spirit of this
approach, since most of the changes between Draft 11 and Draft 11.1
were fairly minor clarifications of the wording.

One advantage of the ``changes-only'' approach is that it helps to
prevent balloters from commenting on those items that have not changed
since the last draft.  This is a restriction placed on recirculation
ballots. You can't object to something you can't see!

The complete Draft 11.1 document is available from the IEEE for
copying costs.  Draft 11.2 is already in the works, and should appear
sometime in September or October.

There have been a few requests lately to amend the POSIX.2 project's
base documents list. This is a list of documents which may be
referenced when discussing existing practice issues.  The OSF's
Application Environment Specification (AES) is one such candidate for
addition.

Draft 9 of POSIX.2 is currently an ISO committee document.  The ISO
standards process sees a document move through three phases on its way
to standardization -- Committee Document, Draft International
Standard, and finally International Standard.  ISO has requested the
U.S. Member Body to forward to them another draft once it has become
more stable. Draft 11.2 has been recommended for this, when it becomes
available.

Draft 11.3 should be out sometime in December. It should be complete
from a technical standpoint.  Hal Jespersen, the POSIX.2 Chair,
reported that final IEEE approval of POSIX.2 as a full-use standard
will be delayed until all ISO concerns have been addressed. This could
mean postponing the IEEE POSIX.2 standard until the middle of 1992. I
don't completely understand why the ISO concerns cannot be addressed
now, through ISO responses to the Committee Documents sent to them.
This will no doubt be discussed heavily in the months ahead.

POSIX.2a Status

Ballot resolution for POSIX.2a (UPE) Draft 6 was completed.  There
were only 400 objections. Draft 7 was produced and recirculated, and
the ballot closed August 19. Ballot resolution is ongoing.

The list of POSIX.2a utilities is now stable. There should not be any
additions or deletions. The technical content of the standard should
be wrapped up in the first quarter of 1992.  Draft 6 of POSIX.2a was
submitted to ISO as a proposed Committee Document/Proposed Draft
Amendment (PDAM) for eventual balloting as ISO 9945-2, Amendment 1.
Due to some procedural problems, it was changed to a Review and
Comment draft.  The next draft of POSIX.2a will likely be Draft 8, a
full draft.  This will also be forwarded to the ISO, as a Proposed
Draft Amendment, and will hopefully make it this time.  Expect the
approval of POSIX.2a as a full-use standard anywhere from three to six
months after POSIX.2.

Project Management Committee Review

Both POSIX.2 and POSIX.2a are up for review by the Project Management
Committee (PMC) in October. Each project will be examined to ensure
that the work is fulfilling its mandate.

The PMC has recommended that the proposed project request (PAR) for
POSIX.2b deal strictly with new utilities. The ISO timing and
formatting issues originally included in the scope of POSIX.2b were
thought to be unnecessary.

POSIX.2b will include utilities from the other POSIX working groups.
These working groups may allocate chapters in the standard in a
similar fashion to POSIX.2a.  Each group retains control of its
chapter.  This is preferable to delegating the specification of the
utilities to the existing POSIX.2 working group, which may not have the
required expertise.

One question arose from this: as the work of other groups is
integrated into POSIX.2 should those other groups' base documents
automatically be added to those of POSIX.2?

New PAX Archive Format

Work continued on the new PAX archive format. No new proposals were
forthcoming, and the group continued working in its current direction.
The intent is to build a new archive format on top of the ISO 1001
tape standard. The current new format specification does not draw a
clear line between what is part of the ISO format, and what was added
for PAX.  This will be remedied in a subsequent draft.

I have reconsidered my earlier challenges to basing this new format on
ISO 1001. It does have tangible benefits, and should make transferring
tapes between non-traditional environments easier. The current
proposal addresses both tape and non-tape based formats.

Unfortunately, the current POSIX.2 working group does not seem to have
a great deal of enthusiasm for this project.  Progress is slow.
Unless someone champions this new format, it may well stall. Mark
Brown (IBM) has volunteered to flesh out the current draft for
distribution in the next POSIX.2 mailing.

Test Plans and Assertions

A test plan for POSIX.2 and POSIX.2a was written, and submitted to
POSIX.3.2 (Test Assertions for POSIX.2) for review.  Lowell Johnson,
POSIX.3.2 Chair, expressed some concerns over the linkage of the
POSIX.2 and the POSIX.2a test plans. It is important that each test
plan cover the scope of one and only one project.

Tuesday to Friday were spent writing test assertions in a joint
meeting between POSIX.2 and POSIX.3.2.  Confusion continues to reign
when writing assertions. There are many different assertion styles,
and it seems to be more art than science.  Styles range from ``you
know what I mean'', to precise, verbose, legalese. The group requested
that the Chair (Lowell Johnson) and the Technical Editor (Andrew
Twigger) produce a style guide for POSIX.3.2 assertions.  The guide
would be reviewed at the beginning of each joint meeting. This should
greatly help the consistency of the assertions being produced.

Draft 5 of POSIX.3.2 is now 400 pages, and most of the POSIX.2
commands have assertions. The group is still intending to mock ballot
the document after the October meeting.  A few utilities are
noticeably absent: awk, lex, and yacc. I'm sure donations of good
assertions for these utilities would be most welcome.

The turnout for the joint meetings was disappointing.  Writing test
assertions is time consuming hard work.  Ideally the joint meeting
time should be spent reviewing assertions, and clarifying the implied
interpretations of the standard. Unfortunately, it is difficult for
members to find the time between meetings to write assertions.

Writing test assertions for POSIX.2a will likely start in January
1992.  If you thought test assertions for make were difficult, wait
until you try vi!

Volume-Number: Volume 25, Number 13

From [e-mail]  Fri Sep  6 14:51:14 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02220; Fri, 6 Sep 91 14:51:14 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03184; Fri, 6 Sep 91 14:51:04 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.4, POSIX.4a, POSIX.4b, POSIX.13: Realtime POSIX
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.4, POSIX.4a, POSIX.4b, POSIX.13: Realtime POSIX

Bill O. Gallmeister <[e-mail]> reports on the July 8-12, 1991
meeting in Santa Clara, CA:

Summary

The working group continued work on Application Profiles, on the
extended POSIX.4b Realtime Proposals, and on the thorny issues of IPC
and synchronization mechanisms. Since both POSIX.4 and POSIX.4a are
preparing for another ballot recirculation, there was little work done
on these drafts.

Real-time Application Profiles

POSIX.4 has produced four different profiles, matching different
scales of real-time endeavor.  The Embedded profile is meant for small
machines that may lack hardware for paging, disks, and terminals.  As
such, this profile is rather different than what is generally
considered to be a UNIX(TM) system.  In particular, the threads work
is called out, and some of the POSIX.1 file system, but fork() is not
needed.

This requires subsets of POSIX.1.  Its multiprocess aspects and a lot
of the extended filesystem semantics are considered optional by the
people working on the smaller Real-Time profiles.  This subsetting
work has to be sanctioned by POSIX.1.  Getting them to agree to this
work may be an interesting task.

Other profiles under development are a ``Controller'' profile, an
``Avionics'' profile, and the ``Kitchen Sink'' profile.  The Kitchen
Sink and the Embedded profiles define two endpoints of a spectrum of
real-time practice.  The Controller and Avionics profiles define
particular points of practice within that spectrum.  The Avionics
profile reflects the current requirements of the Avionics industry.
The Controller profile is a step up from the Embedded profile.

IPC Again

POSIX.4 inter-process communication (IPC) remains an issue.  We had a
liaison meeting with the POSIX.12 (Protocol Independent Interfaces)
working group and presented our requirements for a Real-Time sockets
mechanism.  There were 28 possible requirements; we decided that 17 of
these requirements were truly necessary for a socket-based mechanism
for Real-Time IPC.  The POSIX.12 group helped us refine these
requirements into something they can use in defining a mechanism.
These discussions will undoubtedly carry on for some time.

Meanwhile, the existing POSIX.4 IPC chapter is undergoing radical
surgery.  The recirculation draft that should come out this October
should feature an IPC mechanism that more closely resembles the
message passing interfaces of small real-time kernels.  The
interaction of this message-passing mechanism and the future POSIX.12
real-time sockets mechanism is an open issue.

Synchronization Again

At the last meeting, it was the POSIX.4 proposal that needed guidance
from the working group on its binary semaphores chapter.  This
meeting, the POSIX.4a proposal required guidance with regards to
mutexes.  (Mutexes are simple MUTually EXclusive locks.) Specifically,
the priority ceiling protocols in the current draft ran into serious
balloting problems.  In response to this, a simplified version of the
priority ceiling protocol, called Priority Ceiling Protocol Emulation,
was proposed to replace the existing two mechanisms currently in
POSIX.4a.  The emulation protocol is much easier to understand, offers
the same worst-case blocking behavior as the earlier proposals
(although worse average-case behavior), and works with multiprocessor
systems.  The working group was torn whether any priority ceiling
protocol should be in POSIX.4a at all.  Assuming that one would be
present, the group clearly preferred the emulation protocol.

The debates on priority ceiling featured a lively exchange between
POSIX.4 and POSIX.14 (Multiprocessor Profile). This is the closest
that POSIX.4 has come to its old glory days of large bloody group
battles.

POSIX.4b

Some work was done on the timeout extensions of POSIX.4b.  This work
involves providing timeouts to all POSIX.4 calls that may block.  An
early draft of this proposal is available in the latest POSIX.4
mailing.

Future Drafts

The technical reviewers for POSIX.4 and POSIX.4a have been working
hard towards new drafts of each of these documents.  It is our current
plan to recirculate them both at about the same time as the Fall
meeting.  If this happens, the next meeting will again focus on
application profiles and continuing POSIX.4b.




















































Volume-Number: Volume 25, Number 15

From [e-mail]  Fri Sep  6 14:51:22 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02280; Fri, 6 Sep 91 14:51:22 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03249; Fri, 6 Sep 91 14:51:18 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.6: POSIX Security Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.6: POSIX Security Extensions


Ana Maria De Alvare' <[e-mail]> reports on the July 8-12,
1991 meeting in Santa Clara, CA:

Hello USENIX members!

This time my report will be very brief.  It is brief because there
were no big disagreements at the meeting, and because the whole week
was spent in cleaning up the document for formal ballot.

This was the last meeting working in functional subgroups, addressing
discretionary and mandatory access controls (DAC and MAC), audit, and
privileges.  At the next meeting the group will be divided into people
helping with the balloting process, doing test assertions, and
identifying areas that POSIX.6 has not covered.  The ballot document
should come out sometime after the September mailing (September 10,
1991).

POSIX.6 spent the whole week addressing all the mock ballot comments
and objections.  A small group of three people, including myself,
began working on the first draft of the POSIX.6 test methods.  The
test methods draft will be brought to the next meeting and people from
the disbanded subgroups will begin creating test methods for the
functions defined in POSIX.6 document.  It will be a long week!

So what areas aren't covered in the current POSIX.6 draft?  The three
major areas that I know are not covered are:

   - authentication,

   - security system administration, and

   - network security.

There are items in the subgroups which are also not addressed. A
portable audit format has not been fully defined, and so is not going
out for ballot.  With mandatory access controls, we decided at this
meeting to not enforce privileges on an implementation of multi-level
directories.  Except for some clean-up in Draft 11, discretionary
access controls remain the same.

The data type issue still remains across the DAC, MAC, audit, and
privileges subgroups.  To interoperate between systems, opaque objects
need to be stored and retrieved without concern for the implementation
defined formats. An opaque object model also provides consistency
across the interfaces. POSIX.6 subgroups have defined a number of
security related objects. We cannot agree on a way to represent these,
but have determined four possibilities:

   - A Type 1 object is opaque, and is only valid for use by the
     process which gets the data, and only for the lifetime of the
     process.

   - A Type 2 object is still opaque, but it must be self-contained
     and persistent.

   - A Type 3 object is a text string with an undetermined format.
     MAC labels are represented as Type 3 data types.

   - A Type 4 object is a text string with a defined format.  Access
     Control Lists (ACLs) have a Type 4 representation.

One compromise was that the subgroups would define conversion routines
for Type 2 and 3 data, which would return an opaque object and the
length in bytes of the object.

We were still unable to agree upon a uniform type representation
across the four subgroups in the July meeting. This issue will likely
be a hot one in the balloted document.  We will have to wait and see
what the ballot brings to resolve this.

Well, that's all folks!  Keep an eye out for the POSIX.6 ballot.

Volume-Number: Volume 25, Number 16

From [e-mail]  Fri Sep  6 15:00:35 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06149; Fri, 6 Sep 91 15:00:35 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05606; Fri, 6 Sep 91 15:00:32 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.12: Protocol Independent Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.12: Protocol Independent Interfaces


Tim Kirby <[e-mail]> reports on the July 8-12, 1991 meeting in
Santa Clara, CA:

POSIX.12 is developing a set of protocol independent networking
interfaces.  There are no major changes in direction in the group's
direction this meeting.  Two interfaces are proposed in language
independent form - the simple network interface (SNI) and the detailed
network interface (DNI). SNI is a proposal drawn from several sources,
with no existing (de-facto) standard. DNI, however, is seen as a
single language independent specification to which there are two valid
C language bindings, one for BSD- style sockets and one for the X/Open
Transport Interface (XTI).

The group once again reviewed the proposed changes to XTI option
management from Gerhard Kieselman, following input from X/Open during
the intervening three months.

A significant amount of time was spent in liaison with the Transaction
Processing (POSIX.11) and Real-Time (POSIX.4) working groups as a
result of the proposal from the last meeting to include their
requirements in the POSIX.12 interface. POSIX.4 requirements are a
direct result of ballot objections to the IPC interface proposed in
their current draft. Given the announced intention of POSIX.4 to
include a ``simple'' IPC interface regardless of the POSIX.12 efforts,
there is some concern within our group that there are no advantages to
the proposed POSIX.12 changes.

Work between the meetings continues on language independent versions
of the interfaces, and the test methods without which the document may
not become a standard.

A review of the test method requirements revealed a significantly
larger amount of work than had originally been anticipated. This has
resulted in a change to the test method schedule. The mock ballot of
the POSIX.12 draft is not expected now before the second quarter of
1992, and the first real ballot not before the fourth quarter of 1992.

Volume-Number: Volume 25, Number 17

From [e-mail]  Fri Sep  6 15:00:40 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06181; Fri, 6 Sep 91 15:00:40 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05624; Fri, 6 Sep 91 15:00:36 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.17 - Directory Services API
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.17 - Directory Services API


Mark Hazzard <[e-mail]> reports on the meeting in Santa
Clara, California:

Summary

POSIX.17 made significant progress towards completing another draft in
Santa Clara.  The group is on track to mock ballot Draft 2.0 of the
Directory Services API by the end of August.  Key areas of progress
were:

   - test methods,

   - language independence specification (LIS),

   - Model text in Section 3,

   - ds_gethostbyname() example,

   - preparation for mock ballot.

Introduction

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

XOM is a stand-alone specification with general applicability beyond
the directory services API.  It will be used by IEEE 1224.1 (X.400
API) and possibly other POSIX groups.  It is being standardized by
IEEE 1224.

Status

Commitment within the group remains strong, with all Chicago attendees
returning to Santa Clara, and completing homework assignments.  We are
committed to mock balloting our document between meeting cycles and
have planned a special mailing for the end of August, (paid for by
X/Open - Thanks!).

Once again, considerable time was spent examining POSIX.12 (Protocol
Independent Interfaces) requirements for directory services. One of
the requirements is a mechanism to protect existing applications from
changes in how directory services are offered.  We had decided that
this was technically beyond the scope of our work, but that we would
address this by providing a non-normative annex with coding examples,
showing how it could be done.

The first example is a new function, ds_gethostbyname(), which could
be added to the existing practice API (BSD's gethostbyname()
function).  With it (or something similar) existing applications
wouldn't need to be modified to work in a POSIX environment.

Another POSIX.12 requirement was that the underlying directory service
provider be able to interoperate/co-exist with existing practice
directory services (e.g. the Internet DNS).  On the surface, impact to
the API itself is minimal, requiring (at most) the use of an existing
parameter which would allow the application to specify which (of many)
services it wanted to use.

POSIX.17 and P1224 (XOM API) met in joint session to review the object
management specification.  Many corrections were made, and a new draft
will be released in the first half of August (in time for our Mock
ballot).

Mock Ballot

There were many homework assignments this time to get the mock ballot
out between meetings.  Significant progress was made towards producing
a draft suitable for mock ballot.  The technical editor completed his
assignment to provide 25% of the LIS text.  An estimated 25% of the
test assertions were completed as well.  Our plan is to go to mock
ballot with this level of completeness in order to obtain feedback
before we proceed further.

We plan to send it out before the end of August, so we'll be able to
process the feedback at our next meeting.  Hopefully, we'll get
feedback on our LIS and test assertion work The comments will help us
determine our future direction and better estimate our completion date.

In Closing ...

The group made good solid progress in Santa Clara readying the
document for mock ballot.  We seem to uncover more requirements with
each meeting but somehow we're managing to move forward.  POSIX.17
will be mock balloted incomplete, needing more work on LIS, test
methods and a few more examples.

The group will meet in October to process the input from our mock
ballot, continue working on LIS and test methods, and determine where
we go from there.  As usual, there's a lot of work to do.

Volume-Number: Volume 25, Number 18

From [e-mail]  Fri Sep  6 15:00:44 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06206; Fri, 6 Sep 91 15:00:44 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05642; Fri, 6 Sep 91 15:00:41 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, P1224: X.400 API
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
P1224: X.400 API


Steve Trus <[e-mail]> reports on the July 8-12, 1991
meeting in Santa Clara, CA:

Summary

P1224 is producing two documents for standardization - the X.400 API
and the X/Open Object Management API (XOM). At Santa Clara, the group
continued work on the modifications required to the base documents.
Specifically the group:

   - reviewed the first draft of the Object Management API,

   - worked on test methods,

   - worked on IEEE balloting plans for P1224.

The IEEE Standards Board has approved the Project Authorization
Requests (PARs) for P1224 (OSI Object Management API) and P1224.1
(X.400 API).

Report

The Santa Clara meeting was generally productive for the P1224 working
group, and we are well under way to producing our draft documents for
standardization. Progress wasn't what it could have been due to
minimal participation by the X.400 API Association.

Review of Object Management Draft

The first draft of the Object Management API was distributed to the
P1224 working group before the meeting.  The group spent much of the
week reviewing the API.  The POSIX.17 (Directory Services) group
joined the review for one day.  Numerous changes were made to the
document.  When the changes have been incorporated into the document,
it will again be sent out in the P1224 mailing.

Test Methods

Tony Cincotta, a test methods expert from NIST, spent much of the week
reviewing the Object Management draft and test methods already
developed.  Tony provided many suggestions for improving the test
methods developed thus far.

It has become apparent that the development effort required to build
test methods for the X.400 and Object Management APIs could delay the
completion of balloting of the APIs for years.  To resolve this
problem X/Open is considering funding a contractor to develop the test
methods for these documents.  This issue should be resolved by the next
meeting.  Additionally, Tony recommended that he train the X/Open
contractor for the development of the test methods section of the
documents.

Balloting Plans

Our current plans are to ballot the Object Management API after the
October meeting, and to ballot the X.400 API after the January
meeting.  These ballots would not include the test methods; Balloting
cannot complete until the test methods are complete.

Currently we are developing the list of people who will be invited to
ballot these documents.  This list includes members of the IEEE TCOS,
the X.400 API Association, and X/Open Limited.  Invitations to join
the balloting group will be sent out at the end of August by the
IEEE.  To be included in the balloting group, a person must return the
invitation to the IEEE by October 10, 1991.

Iain Devine, the P1224 technical editor will be the ballot resolution
reviewer, assisted in technical matters by Enzo Signore.

In Closing

P1224 continues to make good progress. The primary focus of the
Parsippany meeting will be to continue the review of our draft
documents, work on our test methods, and prepare for balloting.
























Volume-Number: Volume 25, Number 19

From [e-mail]  Fri Sep  6 15:00:51 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06250; Fri, 6 Sep 91 15:00:51 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05650; Fri, 6 Sep 91 15:00:47 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, ANSI and the X3 Committees
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on ANSI and the X3 Committees


John Hill <[e-mail]> discusses ANSI and the X3 committee:

Over the past few years information technology standards have become
more important in the industry. One of the most prevalent areas for
standardization is operating systems and allied services.  This
article discusses the largest formal standards development
organization for information technology in the USA, X3, and its
relationship to ANSI.

A brief background is useful in understanding how the USA develops
standards.  The premier standards body is the American National
Standards Institute (ANSI).  Its four main functions that are of
interest here are:

   - membership in the International Standards Organization (ISO) and
     the International Electrotechnical Commission (IEC), the
     worldwide standards bodies,

   - accreditation of organizations to develop voluntary U.S.
     standards,

   - publication of U.S. national standards,

   - oversight of the standards development process to ensure due
     process and fairness.

That's right, ANSI does not develop standards; ANSI accredits other
organizations to develop standards.

Standards are developed in one of three ways:

   - by professional and trade organizations (e.g.  Institute of
     Electrical and Electronic Engineers, IEEE, an organization which
     is involved in more than the development of standards),

   - by accredited committee (X3),

   - by canvass (e.g.  Ada Joint Program Office, AJPO).  The canvass
     method is intended for mature and non- controversial standards
     processing.

In a nutshell, ANSI accredits the standards development procedures of
individual groups within some designated, but very broad scope, and
according to one of the three ways.

X3, while not a part of ANSI itself, is an example of a committee that
ANSI has accredited to develop U.S. national standards.

X3 was established in 1961.  Since its inception, the Computer and
Business Equipment Manufacturers Association (CBEMA) has functioned as
the secretariat.  X3 has about 850 projects, 200 standards, and some
3000 volunteers.

The purpose of X3 is voluntary standardization in the areas of
computers, information processing, and peripheral equipment and
devices.  This scope of activity includes standardization of
subsystems in order to provide for hardware interoperability and
software portability.  As a result, many of the fundamental standards
of the computer industry have been developed by X3.

The true, nuts-and-bolts work of X3 is done by its subgroups.  There
are two types of subgroups, advisory and technical.  The three
advisory committees are collectively empowered to ensure that the
process of standards development is under control.  These advisory
committees are chartered to

   - advise the secretariat in administrative activities,

   - develop the X3 strategic plan,

   - manage the technical activities of X3.

The forty technical committees of X3 actually develop the standards.
There are committees for:

   - media (both magnetic and optical),

   - operating system services (database and graphics),

   - programming languages (Fortran, C, COBOL),

   - codes and character sets,

   - vocabulary,

   - data communications (OSI),

   - systems technology (SCSI, security),

   - and office systems (ODA/ODIF).

These technical committees frequently act as the U.S.  technical
advisory groups (TAGs) for the development of worldwide standards.

Worldwide standards are a major area of activity for X3.  Over the
past ten years, the X3 member organizations have expended more
resources for development of the base OSI standards than on any other
single functional area of standardization.  These 175 largely
anticipatory standards were developed for the most part in the
international arena.  The US delegates from the X3 technical
committees actively worked in SC21, the ISO/IEC subcommittee
responsible for the OSI standards, to ensure that US interests were
met in the worldwide standards being developed.

Membership in X3 is open to anybody affected by its standards.  Its
current members, of about 41, include some of the most notable
producers, users, and general interest groups involved in the
information technology industry.  Members have to participate in order
to remain in good standing.

All members pay annual service fees to support X3 activities.  The
larger members pay more than the smaller.  An additional fee is
charged for participating in the subgroups.

If you have further questions concerning X3, you should contact the X3
secretariat (202-737-8888).  These helpful people can send you several
standing documents which expand upon this discussion.

Volume-Number: Volume 25, Number 20

From [e-mail]  Fri Sep  6 15:00:57 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06314; Fri, 6 Sep 91 15:00:57 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05669; Fri, 6 Sep 91 15:00:53 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on ANSI X3B11.1: WORM File Systems

Andrew Hume <[e-mail]> reports on the July 17-19, 1990.
meeting in Murray Hill, NJ:

Introduction

X3B11.1 is working on a standard for file interchange on random
access, write-once media: a portable file system for WORMs.  First let
me apologize for tardy snitching (again); my excuse this time is that
I am now technical editor of the working paper.  I shall describe the
results of the last two meetings, April (North Falmouth, RI) and July
(Colorado Springs, CO), as a summary of where we are now.  In brief,
the current draft seems fairly stable and we expect to conduct a
letter ballot after the next (October) meeting.  There is also
considerable international activity.  I also discuss our method of
electronically distributing our drafts.

International Activity

I am still a novice at international standards stuff so take the
following with a larger than normal grain of salt.

The appropriate ISO committee, SC15, has been reconstituted and had
its first meeting in several years in July in Tokyo.  The meeting was
mostly administrative in nature but there was a proposal for a volume
structure standard submitted by Fujitsu.  The motivation for this is
that Fujitsu intends to introduce 3.5in media and drives that can be
partially embossed (like CD-ROM) and partially WORM or rewriteable.
Understandably, they would like to have a standard volume labelling
scheme to enhance interchange.  They figure that file system layout
standards can come along later but we need the volume labelling scheme
Real Soon Now.

A common way for an ISO committee to do work is invite some
recognized, accredited committee to submit a proposal and then vote on
it.  In particular, some committee with relatively little
administrative procedure.  This means ECMA, (European Computer
Manufacturers Association,) and not ANSI.

Luckily, the relevant ECMA committee, TC15, has just been
reconstituted with its next meeting in Geneva in early September.
Ostensibly, TC15's first job is to consider and bless the work of the
Frankfurt group, which has been working on an extension of ISO 9660
(CD-ROM) to handle CD-WO media.  The very next thing will probably be
a volume structure and file system standard, based on our (X3B11.1)
work.  (This has required significant changes to our working paper but
more on that below.)

There is also a dark side to TC15.  ECMA apparently has a hidden
agenda for TC15 that includes the development of a general storage
architecture.  This is the storage equivalent of the OSI networking
model with its 7 layers.  The first guess at the layers are:

   - physical layer,

   - recording layer,

   - formatting layer,

   - volume structure layer,

   - object management/file system layer (e.g.  ISO 9660),

   - file structure layer (e.g.  ISAM),

   - application layer.

Why does the international activity matter?  (That this question needs
to be raised is comment enough for our industry.) The goal of the
standards game is to have a technically sound standard adopted as soon
as possible.  Assume for now that the X3B11.1 draft is technically
sound.  How do we get a standard?  One way is to go through ANSI
procedure, like the C standard did.  Assuming no problems, hitches,
objections and foulups, we could have an ANSI standard within two
years.  And then we would have to work within the ECMA/ISO committees
to ensure that they adopt a technically equivalent standard (and thus
avoid the prospect of an ANSI standard that conflicts with an ISO
standard).  The other way is to work within the ECMA committee and
produce an ECMA standard which then, given the heavy European presence
in ISO, would fairly automatically become an ISO standard.
Astonishingly enough, it seems likely that we could get an ISO
standard 6-9 months sooner than we could get an ANSI standard!  (Yes,
sadly, this means that often the quickest way to get an ANSI standard
is to do the ISO standard via ECMA and have ANSI adopt the ISO
standard.)

The Current Draft Working Paper

In order to facilitate adoption of the working paper by TC15, we have
made several structural changes to the working paper.  It is now in
four parts.  The first part is introductory.  It specifies the scope
and defines terms.  The second part describes a volume labelling
scheme. It specifies how volumes are labelled, how partitions are
defined, how volumes are grouped into volume sets and a bad sector
replacement scheme.  The third part describes a file system layout
that is independent of the details of part two.  The fourth part is a
short section detailing the (very few) changes needed to make part
three suitable for rewriteable media.  This restructuring was a
significant labour, although it involved negligible technical change.

Volume/Partition Structure

This part is probably the most changed since my last report.  It has
become much simplified and made independent of the file system
specification.  It handles space allocation for the volume, recording
of volume and partition descriptors, definitions of partitions, and
bad-block mapping.  Provision has been made for specifying the type of
file system in a partition.  Some of these will be predefined, such as
ISO 9660 and 9223.  Others can be registered, such as proprietary
formats like SGI's EFS file system.

File System

This has been fairly stable although many details have been tweaked.
The space management within a partition and integrity controls
(essentially the dirty bit for a partition) have been moved out of the
volume description and into the file system description as it was
deemed too complicated to demand everyone support it.

Technical Editing

Because of the previous technical editor's health problems, I was
appointed technical editor.  This has been quite entertaining for me;
I have never been involved in such a complicated document production
(and all of it my own doing!).  A single processing pass produces a
table of contents, an index, automatically generated data structure
layouts, ANSI C declarations of all the data structures, an ANSI C
program that tests that the declarations are correct on your system
(the fields have the correct offsets and sizes), and last but not
least, the troff output.

Each pass runs at least 8 awks, 4 sorts, 10 seds, 2 uniqs, spell, tbl,
eqn, troff and Kernighan and Van Wyck's balancing page makeup
backend.  It takes 6 minutes clock time on a 80 mips SGI
multiprocessor.  (This may not be a game for PDP-11s anymore but at
least I know what to do with all those cycles!) We iterate until
nothing changed since the last pass.

A more noteworthy accomplishment (than writing more awk scripts than
you can point an editor at) is that the current draft of the working
paper is available online by both ftp and email (netlib).  You can get
either of two forms:  PostScript and the troff input (minus all the
formatting directives).  This way you can print your standard and grep
it too.  The files are x3b11.1-wp.ps and x3b11.1-wp.text and are in
the directory research/memo.  For ftp, login as netlib on
research.att.com.

Finale

What can, or should, you do?  Well, the worst case is that a standard
based closely on the current draft will become an ISO standard for
interchange for all random access disk drives (optical and magnetic).
You not only would have to support it; you may have to boot off such a
disk.

If you wish to comment on the draft, the best time would probably be
in early November during the letter ballot.  (You of course can't be
in the letter ballot because you aren't a member but you could give
your comments to me.)

If you would like more details on X3B11.1's work, you should contact
either me ([e-mail], 908-582-6262) or the committee
chair, Ed Beshore.  I think the two most useful documents are the
current draft of the working paper (about 60 pages) and a programmer's
guide to the draft (about 12 pages written by me).  I will send you
copies of the latter document; requests for other documents or more
general inquiries about X3B11.1's work would be best sent to Ed
Beshore.

The next meeting is in Merrimack, NH on October 21-25, 1991.  Anyone
interested in attending should contact either me or Ed Beshore
([e-mail]).

Volume-Number: Volume 25, Number 21

From [e-mail]  Fri Sep  6 15:01:35 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06609; Fri, 6 Sep 91 15:01:35 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05796; Fri, 6 Sep 91 15:01:27 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, X3J16: C++
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Thu, 5 Sep 1991 08:53:29 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on X3J16: C++


Mike Vilot <[e-mail]> reports on the June, 1991 meeting in
Lund, Sweden:

Current Status

The ANSI X3J16 committee took a major step towards
internationalization at its June meeting.  This was the first joint
meeting between X3J16 and ISO WG21.  WG21 is the ISO C++ working
group.  X3J16 and WG21 are roughly peer organizations.

June meeting

The Lund Institute of Technology hosted the meeting in Sweden.  The
week's major activities focused on understanding the myriad details of
producing a single, international C++ language standard.

The X3J16's sub-groups focus was on the key topics listed in the goals
statement developed at the March, 1990 meeting.  They worked by
electronic mail between meetings, and reported their progress.

International Concerns
Steve Carter, of Bellcore, presented the major international concerns:

International cooperation is an explicit goal of X3J16, and the
committee devoted the entire first day's discussion to international
concerns.  Most members want to avoid the difficulties encountered
during the development of the C language standard.

Much of the work focused on attaining a smooth coordination with WG21
without losing technical effectiveness.  The committee agreed to
continue emphasizing informal discussions and informal "straw votes"
before making formal decisions.  All members of WG21 will be added to
the email lists, and will receive X3J16 paper mailings.

On the other side, WG21 voted to hold its technical meetings jointly
with X3J16.  They appointed Jonathan Shopiro as their editor, which
means both committees have the same editor.

X3J16 decided to conduct a letter ballot on the question of converting
to a Type "I" process.  This means developing an international
standard, rather than developing a domestic standard followed by an
international standard (as was the case for the C language).  A straw
vote indicated most members would vote in favor of the change.

The committee dissolved the International Concerns working group,
since it has served its purpose. Steve Carter, serving as Convener of
WG21, will continue to address international C++ concerns.

Editorial
Jonathan Shopiro, of AT&T, presented the Editorial group's work:

The editorial change that simplified the treatment of names and name
lookup, merging the concepts that had previously been treated under
the topics of dominance and name hiding, remained in the document.

Much of the recent work on the document has been in clarifying or
defining basic terms. For example, the basic unit of storage is a byte
In the C standard, it is a character, which confuses the notion of
what type "char" is supposed to represent, especially in light of
8-bit and larger character sets.  The process of resolving the
definitions of the two base documents continues.  (These are the
Annotated C++ Reference Manual and the C standard.)

One minor change to the document format: the size is now suitable for
A4 paper.

Formal Syntax
Reg Charney, of Program Conversions, presented the work of the Formal
Syntax group:

The bulk of the discussion concerned the change that renamed most of
the non-terminals in the grammar.  There are still more proposed
changes.

The conflict between the virtues of regularizing the naming versus the
evils of gratuitous changes resurfaced.  Bjarne Stroustrup made the
strongest criticism, observing that the changes had been proposed and
adopted without sufficient principles.  He noted that the lack of such
principles invited the kind of "random changes" that were presented at
the June meeting.  He also observed that the changes had not even been
checked against the C standard's grammar.

Core Language
Andy Koenig, of AT&T, presented the Core Language group's work:

Most of the Core Language discussion centered on name resolution
issues.  These issues are highlighted by the interactions of nested
classes, inline friend function definitions, and static class members.

This work has helped identify ambiguities in the present wording.
Although there has been progress, open issues remain.  For example,
defining a friend function in a class causes the name of the friend to
be made available in an "enclosing" scope.  The cases involving nested
and local classes still have to be resolved.

Environment
John Wilkinson, of Silicon Graphics, presented the work of the
Environment group:

Discussion continued on static initialization order for objects in
different translation units.  The group proposed two new rules
intended to provide correct initialization that still accommodated
dynamic linking:

   - Nonlocal static objects defined in a translation unit must be
     initialized in the order that the definitions appear in the
     translation unit.

   - The nonlocal static objects defined in a translation unit must be
     initialized before any object or function defined in that unit is
     used by any other translation unit; the nonlocal objects defined
     in the translation unit containing main() must be initialized
     before control enters main().

Specifying translation limits in the standard was discussed, but
seemed to generate more heat than light, and nothing was decided.

Libraries
Jerry Schwarz, of Lucid, presented the Library group's work:

There is an evolving proposal for a standard string class, and its
interaction with internationalization concerns.  The tradeoff involves
generality (strings of both single- and multi-byte characters) versus
efficient implementation.  This discussion continues.

The group also worked on issues of conformance, and describing the
options available to implementations that choose to extend the
standard library.  For example, the implementation may provide the
standard classes by deriving them from base classes not mentioned in
the standard, or as instances of templates not mentioned in the
standard.  As another example, an implementation may add members to a
class definition, with the constraint that private virtual functions
must be in the implementation name space.

Work also progressed on standard exceptions.  One line of
investigation is to use exceptions to clarify those aspects of the
language that are vague or "undefined." For example, the default
new_handler could throw a storage_error exception.

Language Extensions
Bjarne Stroustrup, of AT&T, presented the work of the Extensions group:

The group proposed a change that adds digraphs and new keywords as
synonyms for certain characters.  For example, '{' can be written as
'<%', '&=' as 'and_eq', and so on.  This allows expression of C++
programs in character sets that do not include certain of the ASCII
characters.  It is a proposal Bjarne has been working on with Keld
Simonsen for over a year, and their work has been coordinated with the
ISO WG14 (C language).  The committee adopted this proposal.

The group is working through a long list of proposals for changes to
the language.  Some of the items are:

   - adding 8-bit (i.e. international) characters in identifiers;

   - allowing virtual functions in a derived class to use a more
     specific return type than the base class' version of the function;

   - allowing overloading of operator . (dot);

   - a name space control mechanism.

The largest issue currently lurking in the Extensions category is the
addition of support for run-time type information.  There will be much
discussion on this topic over the next months.

C Compatibility
Tom Plum, of Plum-Hall, presented the work of the C Compatibility
group:

The group continued its investigation of the vocabulary differences
between C and C++.  Only a few of the differences have been resolved,
and Tom plans to meet with Jon Shapiro to decide which terms can be
incorporated as C++ definitions.

Next events

The next three X3J16 1991 meetings (and their hosts) will be:

   * November 11-15, Austin TX (TI)

   * March 9-13 (or 16-20) 1992, London, UK (BSI and Zortech)

   * July 13-17 Toronto Canada (IBM)

Membership on an X3 committee is open to any individual or
organization with expertise and material interest in the topic
addressed by the committee.  The cost for voting or observer
membership is $250.  Contact the chair or vice chair for details.

Chair: Dmitry Lenkov
HP California Language Lab
19447 Pruneridge Avenue MS 47 LE
Cupertino, CA  95014
[phone]
FAX [phone]
email [e-mail]

Vice Chair: William M. Miller
Glockenspiel, Ltd
P.O. Box 366
Sudbury, MA  01776-0003
[phone]
email [e-mail]

Volume-Number: Volume 25, Number 22

From [e-mail]  Fri Sep  6 15:09:08 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA09869; Fri, 6 Sep 91 15:09:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07878; Fri, 6 Sep 91 15:09:06 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Thu, 5 Sep 1991 17:45:47 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Karl Heuer) writes:
>A certain vendor's test suite for POSIX compliance expects that code like
>    fp=fopen(fname, "w"); c=getc(fp); /* attempted read from output stream */
>must cause a run-time error (EBADF, I think).  I claim that the behavior is
>undefined.  Who's right?

ANSI C (to which POSIX mostly defers) says that getc() is the same as fgetc()
except possibly implemented as a macro, and the fgetc() spec requires that
the argument be a pointer to an input stream.  Furthermore, section 4.1.6
of the standard is most explicit that invalid argument values given to
library functions yield undefined behavior.
--
Any program that calls itself an OS     | Henry Spencer @ U of Toronto Zoology
(e.g. "MSDOS") isn't one. -Geoff Collyer|  [e-mail]  utzoo!henry

Volume-Number: Volume 25, Number 23

From [e-mail]  Fri Sep  6 15:09:11 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA09876; Fri, 6 Sep 91 15:09:11 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB07898; Fri, 6 Sep 91 15:09:08 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Thu, 5 Sep 1991 21:59:53 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Karl Heuer) writes:
>A certain vendor's test suite for POSIX compliance expects that code like
>    fp=fopen(fname, "w"); c=getc(fp); /* attempted read from output stream */
>must cause a run-time error (EBADF, I think).  I claim that the behavior is
>undefined.  Who's right?

You are.  There is a specification for what errno must be set to IF an
error is detected, but no requirement that this particular error be
detected.  There was certainly no intention of adding overhead to the
traditional macro implementation of getc().

>My own preference, of course, is that the test suite be ruled incorrect.

Well, it clearly is incorrect, but then that is not the first time the
existing test suites have had serious errors.  I don't know how you go
about getting them fixed.


Volume-Number: Volume 25, Number 24

From [e-mail]  Fri Sep  6 15:09:16 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA09897; Fri, 6 Sep 91 15:09:16 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07934; Fri, 6 Sep 91 15:09:13 -0400
Newsgroups: comp.std.unix
From: Fred Zlotnick <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]>
Date: Thu, 5 Sep 1991 17:24:32 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Karl Heuer) writes:
>Submitted-by: [e-mail] (Karl Heuer)
>
>A certain vendor's test suite for POSIX compliance expects that code like
>    fp=fopen(fname, "w"); c=getc(fp); /* attempted read from output stream */
>must cause a run-time error (EBADF, I think).  I claim that the behavior is
>undefined.  Who's right?

A definitive answer should come from the POSIX.1 interpretations committee.
However, the most recent (Draft 12) version of 1003.3.1 (Test Methods for
Conformance to POSIX.1) has the following assertion for fgetc():

    When the stream pointer argument addresses a file descriptor
    that is not open for reading, then a call to fgetc() returns
    a value of EOF and sets errno to [EBADF].

The assertion is based on section 8.2.3.11 of POSIX.1-1990.  (The square
brackets around EBADF are part of 1003.3's assertion notation.) This is
assertion 6 for fgetc(), in section 11.11.4 of the draft.  So it seems
that at least this committee believes that this behavior is required
(assuming, of course that fopen(fname, "w") opens the underlying file
descriptor for writing only.)  Remember, this is not 1003.1, but 1003.3.
Fred Zlotnick                       |    #include <std.disclaimer>
[e-mail]                  |    #include <brilliant.quote>
...!{uupsi,ames}!mindcrf!fred |


Volume-Number: Volume 25, Number 25

From [e-mail]  Fri Sep  6 19:25:50 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA01733; Fri, 6 Sep 91 19:25:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10841; Fri, 6 Sep 91 19:25:47 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Fri, 6 Sep 1991 23:03:35 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>ANSI C (to which POSIX mostly defers) says that getc() is the same as fgetc()
>except possibly implemented as a macro, and the fgetc() spec requires that
>the argument be a pointer to an input stream.  Furthermore, section 4.1.6
>of the standard is most explicit that invalid argument values given to
>library functions yield undefined behavior.

Undefined in the context of the C standard, not necessarily for POSIX.
POSIX and other standards can impose additional requirements, and in
fact for the Standard C I/O functions POSIX.1 does so, although only a
few of them attempt to give standard meanings to what are called
undefined or implementation-defined behavior in the C standard.

On the other hand, POSIX etc. should NOT try to give standard semantics
to usage that violates C standard syntax rules or constraints, because
those require diagnostics and there are alternative ways to add
extensions that would not make simultaneous conformance to multiple
standards impossible (or impractical).


Volume-Number: Volume 25, Number 26

From [e-mail]  Fri Sep  6 19:35:46 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA05024; Fri, 6 Sep 91 19:35:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13264; Fri, 6 Sep 91 19:35:43 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Fri, 6 Sep 1991 23:15:03 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Fred Zlotnick) writes:
>A definitive answer should come from the POSIX.1 interpretations committee.
>However, the most recent (Draft 12) version of 1003.3.1 (Test Methods for
>Conformance to POSIX.1) has the following assertion for fgetc():
>    When the stream pointer argument addresses a file descriptor
>    that is not open for reading, then a call to fgetc() returns
>    a value of EOF and sets errno to [EBADF].
>The assertion is based on section 8.2.3.11 of POSIX.1-1990.  (The square
>brackets around EBADF are part of 1003.3's assertion notation.) This is
>assertion 6 for fgetc(), in section 11.11.4 of the draft.  So it seems
>that at least this committee believes that this behavior is required
>(assuming, of course that fopen(fname, "w") opens the underlying file
>descriptor for writing only.)  Remember, this is not 1003.1, but 1003.3.

I assert that they have misread POSIX.1-1990.  My copy does not appear
to require that an error be reported, but says only that IF and WHEN it
happens to be reported, errno will be set to the same code as the
POSIX.1 requirements for the "underlying call" read().  Such phrasing
is deliberately aimed at permitting efficient implementations rather
than having to probe for usage errors on every single invocation.

This rather typifies the problems that the UNIX standards validation
industry has had ever since I can recall.  SVVS, for example, was
notorious for verifying that certain reasonable operations would
reliably report failure, rather than being allowed to succeed when
vendors had managed to figure out how to provide extended services.

There are only a relatively small number of circumstances under which
it is important for certain attempted operations to definitely fail,
in a UNIX-like environment.  For the most part, people drawing up the
various system interface standards in recent years have been aware of
this and have not insisted on failure for standard conformance except
in those few important cases.  To do otherwise would stifle innovation.

If the people drawing up the test criteria don't understand this, or
cannot correctly interpret what POSIX.1-1990 actually says, they should
either learn better or else stop what they're doing before it adversely
affects our industry.


Volume-Number: Volume 25, Number 27

From [e-mail]  Fri Sep  6 23:37:10 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA17256; Fri, 6 Sep 91 23:37:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB17975; Fri, 6 Sep 91 23:37:08 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: The Unimplemented/Invented/Premature/Failed Standards Chart, 9/6/91
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
Date: Sat, 7 Sep 1991 02:49:45 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

``Unimplemented'' means that the standard was a requirement for
implementors before any implementations existed. ``Invented'' means
that the standard was not based entirely upon prior practice in the
industry. ``Premature'' means that advances in technology showed the
standard to be ill conceived within a few years of its introduction.
``Failed'' means that many or most of the intended users of the standard
actively avoid using it. Parenthetical notes indicate examples of how
the standard is premature or provide evidence of its failure.
``Unknown'' means that the standard has not yet been implemented widely
enough to judge one way or the other.

Name        Unimpl.    Invent.    Premature        Failed
POSIX.1        yes    yes    yes (job control)    unknown
POSIX.2     yes    yes    unknown            unknown
POSIX.12    yes    yes    unknown            unknown
POSIX.17    yes    yes    unknown            unknown
IEEE 854    ?    no    apparently not        no
C (K&R, pcc)     no    no    no            no
ANSI C        yes    no?    ?            ?
Ada        yes    yes    yes (OOP)        yes (c2ada)

This chart will be posted periodically or at the whim of its editor.
Contributions, updates, and corrections are welcome; send mail to
[e-mail].

---Dan

Volume-Number: Volume 25, Number 28

From [e-mail]  Sun Sep  8 01:33:14 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA26477; Sun, 8 Sep 91 01:33:14 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20696; Sun, 8 Sep 91 01:33:11 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: fixing broken test suites
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]>
Date: Sun, 8 Sep 1991 00:51:01 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Doug Gwyn) writes:
>Submitted-by: [e-mail] (Doug Gwyn)
>
>In article <[e-mail]> [e-mail]
>(Karl Heuer) writes:
>>My own preference, of course, is that the test suite be ruled incorrect.
>
>Well, it clearly is incorrect, but then that is not the first time the
>existing test suites have had serious errors.  I don't know how you go
>about getting them fixed.

You get definitive proof that the test suite is incorrect
(often in the form of an interpretation from the appropriate
standards committee) and notify the test suite developer.

This particular case is a bit more complicated because three
standards are involved (Standard C, 1003.1, 1003.3.1), but the
principle is the same.  Get 1003.1 and X3J11 to affirm that the
assertion is incorrect, get 1003.3.1 to fix the assertion, and
the test suite developers will fix their tests.  I'm in the
process of doing exactly this, over the issue of whether it's
conforming to implement setjmp() and sigsetjmp() as functions
rather than as macros.

Unlike some earlier test suite developers, developers of POSIX.1
test suites have a vested interest in seeing that their tests
are correct, rather than maintaining bug-for-bug compatibility
with earlier implementations.

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


Volume-Number: Volume 25, Number 29

From [e-mail]  Sun Sep  8 01:33:17 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA26481; Sun, 8 Sep 91 01:33:17 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20705; Sun, 8 Sep 91 01:33:15 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Standards Update, Editorial
Message-Id: <[e-mail]>
Summary: POSIX.1 conformance
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]>
Date: Sun, 8 Sep 1991 00:34:48 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Peter Collinson) writes:
>
>By definition, POSIX.3.1 is not yet a standard, hence no POSIX.1
>conformance test suite actually exists.
>
>Because of the obvious buying power of the U.S. government, most major
>vendors are implementing FIPS 151-1. It is a profile or subset of
>POSIX.1.

It is a profile.  It is not a subset.  FIPS 151-1 does not allow
a vendor to omit any of the functionality of the Standard.  What
it does is to specify how a vendor must choose in some places where
the Standard provides options as to the exact form of that
functionality.

>Test suites exist to test conformance against FIPS 151-1.  These must
>use the test methods described in POSIX.3.1 (still in ballot.) One of
>them was written to an early draft of POSIX.3.1.  Another was written
>by using the AT&T UNIX System V Verification Suite (SVVS) as a base.

I disagree with this terminology.  The three test suites that I
know of all test to the draft POSIX.3.1 standard.  Even the
NIST PCTS, which is the official test method for FIPS 151-1
conformance, does not formalize the requirements of FIPS 151-1
beyond POSIX.1 in test code.

All three (the NIST PCTS, the IBM PCTS, and X/Open's VSX) were
originally developed using early drafts of 1003.3.1, and all
three have been and are being updated on the basis of insights
gained from continued progress in developing the 1003.3.1 standard.

>SVVS dependencies are still being discovered and weeded out of this
>one. It is quite possible to implement something different from the
>FIPS, which would fail the FIPS test suites miserably, yet would
>technically conform to the standard.  (If only there was a way to
>prove it.)

There is a way to prove it, and it's well documented in the
`Certificate of Validation Requirements' document published by
NIST.  Where an implementation conforms to the FIPS but fails a
test in the NIST PCTS, the Accredited POSIX Testing Laboratory
determines that the implementation does, in fact, conform, and
issues an explanation and APTL Resolved Test Code for the
assertion test at issue, which is reviewed by the Certifying
Authority (NIST).

NIST has undertaken not to require that implementators butcher
their systems to accomodate portability problems in the test
suite.  It is up to the implementors to be aware of the
requirements of the FIPS and not to code to the test suite
rather than to the Standard.

Note also that NIST seems to honor the premise that 1003.1-1990 is
a bug-fixed version of 1003.1-1988. I haven't seen them penalize
a vendor for following the new Standard.

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


Volume-Number: Volume 25, Number 30

From [e-mail]  Sun Sep  8 14:45:06 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA05730; Sun, 8 Sep 91 14:45:06 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04739; Sun, 8 Sep 91 14:45:00 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 8 Sep 1991 18:10:07 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Doug Gwyn) writes:

[ A 1003.3 assertion requires that getc() on a  file descriptor
  opened for writing report an error. ]

>I assert that [1003.3.1] have misread POSIX.1-1990.  My copy does not appear
>to require that an error be reported, but says only that IF and WHEN it
>happens to be reported, errno will be set to the same code as the
>POSIX.1 requirements for the "underlying call" read().  Such phrasing
>is deliberately aimed at permitting efficient implementations rather
>than having to probe for usage errors on every single invocation.

I agree with Doug.  See 8.2.3.11 in 1003.1-1990.

>There are only a relatively small number of circumstances under which
>it is important for certain attempted operations to definitely fail,
>in a UNIX-like environment.  For the most part, people drawing up the
>various system interface standards in recent years have been aware of
>this and have not insisted on failure for standard conformance except
>in those few important cases.  To do otherwise would stifle innovation.
>
>If the people drawing up the test criteria don't understand this, or
>cannot correctly interpret what POSIX.1-1990 actually says, they should
>either learn better or else stop what they're doing before it adversely
>affects our industry.

I'm sure that the particular criterion under discussion will
be acknowledged to be defective by 1003.3.1.  Their policy and
their practice are, and should be, to write test criteria that
are exactly as stringent as the requirements in 1003.1, no more
and no less.

Note that this sometimes leads to assertions that differ from the
intentions of 1003.1, where those intentions were not expressed
explicitly or where they were not clear to the assertion writers.
Producing a correct and complete assertion set is part of an
iterative process that requires cooperation among the writers
of the base standard, the writers of the test criteria, the
developers of test suites based on the test criteria, and the
system implementors who run the test suites and have to
rationalize their systems to test suite results.

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


Volume-Number: Volume 25, Number 31

From [e-mail]  Mon Sep  9 04:12:59 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA05326; Mon, 9 Sep 91 04:12:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21288; Mon, 9 Sep 91 04:12:55 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: The Unimplemented/Invented/Premature/Failed Standards Chart, 9/6/91
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Sun, 8 Sep 1991 01:31:10 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>C (K&R, pcc)     no    no    no            no

It's clear from this that you don't know what a standard IS.
PCC certainly did NOT implement K&R (1st Edition) C.  If it
were not for conflicts like that, there would have been no
need to work out a genuine standard for C.


Volume-Number: Volume 25, Number 32

From [e-mail]  Mon Sep  9 14:32:24 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA29388; Mon, 9 Sep 91 14:32:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12386; Mon, 9 Sep 91 14:32:21 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]>
Date: Mon, 9 Sep 1991 14:40:26 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

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

>A certain vendor's test suite for POSIX compliance expects that code like
>    fp=fopen(fname, "w"); c=getc(fp); /* attempted read from output stream */
>must cause a run-time error (EBADF, I think).  I claim that the behavior is
>undefined.  Who's right?

I can't believe some of the responses I've seen to this.  It seems that
otherwise intelligent and rational people lose control of their mental
faculties as soon as they see the word "POSIX".

Apart from one response which quoted POSIX.3.1 draft 12, all the responses
I have seen have been wrong, and many of them are examples of the worst
kind of knee-jerk POSIX-bashing reaction.

The assertion in POSIX.3.1 draft 12 is worded extremely carefully and
is perfectly correct.  Draft 11 was incorrect, and it appears that the
test suite implements the old draft and needs updating to draft 12.
The change from draft 11 to 12 was to replace:

    "When the stream pointer argument is not open for reading"

with

    "When the stream pointer argument addresses a file descriptor that
    is not open for reading"

The change takes account of situations where a write-only stream has a
read-write underlying file descriptor.   This must be the case after an
fopen(f, "w") on Karl's system - there is no other way a getc() after
fopen(f, "w") could succeed because the _filbuf(), or equivalent, would
fail if the fd was not readable.

To align with draft 12, the test suite should change from using
fopen(f, "w") to using creat() or open() with O_WRONLY, followed by
fdopen().

--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 33

From [e-mail]  Mon Sep  9 21:41:00 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA11313; Mon, 9 Sep 91 21:41:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28136; Mon, 9 Sep 91 21:40:58 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Mon, 9 Sep 1991 22:45:02 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>    "When the stream pointer argument addresses a file descriptor that
>    is not open for reading"
>The change takes account of situations where a write-only stream has a
>read-write underlying file descriptor.   This must be the case after an
>fopen(f, "w") on Karl's system - there is no other way a getc() after
>fopen(f, "w") could succeed because the _filbuf(), or equivalent, would
>fail if the fd was not readable.

No, that still misses the point.  It is not desirable to require that
the getc() macro check the mode flags on every invocation.  Reasonable
implementations of getc() can (perhaps not immediately after open, but
certainly at some point later) "believe" the FILE structure buffer
count and pointer members, and that means that an actual I/O system
call, or for example the _filbuf() function, need not occur for most
invocations of getc().  Requiring getc() to always report the usage
error, which would take extra code in its implementation, would make
this crucial bottleneck function less efficient.  POSIX.1 does NOT
require that, and it is wrong for POSIX.3.1 to add that requirement.

I don't think it was just the first getc() after an fopen() that was
the issue, but the more general one of an arbitrary getc().

Care should be taken to distinguish among various classes of "error";
in this example the error is one of programmer misuse of a standard
facility, which is not the kind of thing that needs to be checked on
every invocation at run-time.  That is in contrast to open() reporting
that the specified file does not exist, for example, which is a valid
use of the open() function that needs to reliably indicate that kind of
"error".


Volume-Number: Volume 25, Number 34

From [e-mail]  Tue Sep 10 02:14:52 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA28377; Tue, 10 Sep 91 02:14:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08081; Tue, 10 Sep 91 02:14:49 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: The Unimplemented/Invented/Premature/Failed Standards Chart, 9/6/91
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]>
Date: Tue, 10 Sep 1991 01:45:50 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> >C (K&R, pcc)     no    no    no            no
> It's clear from this that you don't know what a standard IS.

In this case the standard is the de facto standard defined directly by
the pcc source and indirectly by (1) K&R; (2) various documents
describing the internal construction of pcc. I'm sorry if you can't
grasp the concept of a standard defined by its implementation, but
that's exactly what pcc is!

One might argue that original C was premature, because it lacked such
useful tools as void and enum. But pcc *did* have those features and
was the reigning standard for years. Its intended users didn't actively
avoid it. Would anyone argue the fact that it was a successful standard,
while certain unimplemented/invented/premature standards, like Ada, have
been rather unsuccessful?

(Do members of a ``standards'' committee ever recover? Or do they always
remain so infatuated with their pet projects that they can no longer see
true standards chosen by the real world? Followups to sci.psychology. In
the meantime, I'd like to thank the people who've suggested additions to
the chart. Keep 'em coming!)

---Dan


Volume-Number: Volume 25, Number 35

From [e-mail]  Wed Sep 11 02:11:08 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA24504; Wed, 11 Sep 91 02:11:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19756; Wed, 11 Sep 91 02:11:06 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: The Unimplemented/Invented/Premature/Failed Standards Chart, 9/6/91
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 11 Sep 1991 05:35:14 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>In this case the standard is the de facto standard defined directly by
>the pcc source and indirectly by (1) K&R; (2) various documents
>describing the internal construction of pcc. I'm sorry if you can't
>grasp the concept of a standard defined by its implementation, but
>that's exactly what pcc is!

Oh, I know what you think you mean, all right, but you failed to respond
to my real point, which is that PCC implementations CONTRADICTED K&R in
several areas, and thus saying that "(K&R, pcc)" constituted any sort of
"standard" for C is self-contradictory.

In fact the argument that "the" PCC implementation (there were several)
constituted a de facto C standard has been shot down many times.


Volume-Number: Volume 25, Number 36

From [e-mail]  Wed Sep 11 13:41:04 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02162; Wed, 11 Sep 91 13:41:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11558; Wed, 11 Sep 91 13:41:00 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 11 Sep 1991 14:15:19 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Doug Gwyn) writes:

>No, that still misses the point.  It is not desirable to require that
>the getc() macro check the mode flags on every invocation.  Reasonable
>implementations of getc() can (perhaps not immediately after open, but
>certainly at some point later) "believe" the FILE structure buffer
>count and pointer members, and that means that an actual I/O system
>call, or for example the _filbuf() function, need not occur for most
>invocations of getc().  Requiring getc() to always report the usage
>error, which would take extra code in its implementation, would make
>this crucial bottleneck function less efficient.  POSIX.1 does NOT
>require that, and it is wrong for POSIX.3.1 to add that requirement.

There is no such requirement in the POSIX.3.1 assertion!

A legal call to getc() on a stream with a non-readable file descriptor
will always result in getc() trying to read data into the buffer, and
therefore getc() itself doesn't need to do the check, it can leave it
to _filbuf() (or whatever).  The only way a getc() on such a stream
could return without trying to read data into the buffer is if there
has been a buffered write before the getc().  That is why I said "legal
call" above.  A call to getc() after a buffered write is not "legal",
because POSIX.1 (by reference to the C Standard) requires applications
to call fflush() or a file positioning function when switching from
output to input.

I maintain that the POSIX.3.1 draft 12 assertion is correct.  Maybe it
would be better if it stated explicitly "when there are no data in the
buffer", but as far as I can see, it is correct as it stands.
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]

Volume-Number: Volume 25, Number 37

From [e-mail]  Wed Sep 11 17:55:36 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA08596; Wed, 11 Sep 91 17:55:36 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19479; Wed, 11 Sep 91 17:55:34 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 11 Sep 1991 19:36:45 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>A legal call to getc() on a stream with a non-readable file descriptor
>will always result in getc() trying to read data into the buffer...

Please cite chapter and verse of ANSI C or POSIX.1 justifying this.
This is the heart of the problem:  the assertion assumes a specific
implementation technique that is not required by the standards.
--
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  [e-mail]  utzoo!henry

Volume-Number: Volume 25, Number 38

From [e-mail]  Wed Sep 11 18:54:40 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA25431; Wed, 11 Sep 91 18:54:40 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02926; Wed, 11 Sep 91 18:54:24 -0400
Newsgroups: comp.std.unix
From: [e-mail]
Subject: ISO Monitor report: ISO POSIX working group meeting of May, 1991
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 11 Sep 1991 21:14:23 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

[ Production of the following report has been jointly sponsored by
  EurOpen and USENIX.

  The report reflects my personal opinions, not those of either of
  these organizations, or of my employer, Oxford University Computing
  Services.

  I apologise for the late production and circulation.  It's all my
  fault!                            -- DD ]






           Report on ISO/IEC JTC1/SC22/WG15 (POSIX)
               Meeting of 14th - 17th May, 1991
                  Rotterdam, The Netherlands

           Dominic Dunlop -- [e-mail]

                   The Standard Answer Ltd.


 Rotterdam is the largest port in Europe.  Perhaps that's why
 everybody forgets it has an airport.  A nice little airport
 that you can get through in ten minutes -- particularly if
 all the other participants in the POSIX meeting are flying
 into Amsterdam airport and taking the train the rest of the
 way.  But you can't get a meal at Rotterdam airport after
 6pm:  everything has its price.

 One of the prices of creating a standard is that you have to
 do things by the book.  You have to know all the procedures,
 and to be able to demonstrate that you have followed them.
 Fall down in either respect, and, sooner or later, someone
 will notice and require you to put things right.  The
 problem is that the only real way to find out about the
 procedures is to have been making standards for a few years.
 By which time you've made a few mistakes, inadvertently cut
 a few corners, and made a few assumptions which turn out to
 be wrong.

 Guess what.  That's just what the ISO POSIX working group
 has done.

 As a result, the working group1 came up with no fewer than
 48 resolutions and 32 action items at its spring meeting.2
 In fact, there could have been even more resolutions, but
 some were voted down.  Which raises another important aspect
 of standards-making: politics.  I'll deal with that aspect
 last.  For the moment, let me run you through the rest of
 the resolutions:






 __________

  1. That is, Subcommittee 22, Working Group 15, of Joint
     Technical Committee 1 of the International Organization
     for Standardization and the International
     Electrotechnical Commission (ISO/IEC JTC1/SC22/WG15),
     colloquially known as the ISO POSIX working group.

  2. And I should know: I was taking the minutes.  I should
     know by now never to volunteer...












                            - 2 -



                          Exit_OSCRL

 You may recall from [1] that ISO procedures had saddled the
 working group with a moribund project, OSCRL (Operating
 System Command and Report Language) which had its birth in
 the early 'eighties and the first flush of the movement
 towards OSI.  Despite intermittent attempts at
 resuscitation, the corpse would not come back to life.  We
 even called a meeting of past OSCRL experts to write an
 epitaph (or, in ISO-speak, draft a Technical Report) but
 nobody came.  As a result, OSCRL lies buried in an almost
 unmarked grave: our first resolution simply says that
 there's no more to be done, and gives fulsome praise to
 those who participated in the project.

 Let's hope we hear no more of it.  I think we killed it by
 the book...

                        New_Projects_R

 What we hadn't done by the book was get official approval
 from Subcommittee 22, our parent body within ISO, for all
 the POSIX work that we consider necessary.  This goes beyond
 the basic operating system interface, the shell and tools,
 and administration, which we've had on our plate since the
 working group was formed.

 Without going into the detail of the differences between the
 work that we thought had been approved, and that which the
 ISO secretratiat thought had been approved, suffice it to
 say that, at its May meeting, the working group forwarded
 ten New Project proposals (NP's) to SC22.  If approved, we
 will officially be able to work on:

    - Real time and real time extensions corresponding to
      draft IEEE standard 1003.4 and the revision  following
      closely behind it.  The French pointed out that both
      deal with "soft" real time, where one needs things done
      fast and reliably, but no planes fall from the sky3 if
      an interrupt is serviced  a few microseconds late.  We
      may yet get involved with the "hard" real time systems
      which address these needs.

    - Transparent file access; that is, transparent access
      across a network to files on remote systems as defined


 __________

  3. or fail to fall from the sky, I suppose...












                            - 3 -



      by IEEE 1003.8.

    - Protocol independent interfaces:  -- sockets and/or
      Transport Level Interface.  (Current work in the IEEE
      1003.12 working group aims to unify the two
      approaches).  Remote procedure call is excluded so as
      not to conflict with the work of SC214 on the topic.

    - Directory Service in line with the work of IEEE
      1003.17.  This work has to do both with access to X.500
      directory services, and with the naming of POSIX
      objects with addresses which can be looked up using
      those services.

    - User portability extension -- the extension to the IEEE
      1003.2 draft shell and tools standard (IS 9945-2 to be)
      dealing with the tools needed for program development:
      make, vi and so on.

    - System interface extensions for the operating system
      interface: advanced concepts such as symbolic links,
      taken from the forthcoming revision to the current
      standard5.

    - Shell and utility extensions from the revision to draft
      IEEE standard 1003.2.

    - Security changes to the existing 9945-1 standard and
      the forthcoming 9945-2 shell and tools standard.  These
      will be taken from IEEE 1003.6 and will update existing
      standards -- hopefully in a way which does not break
      existing applications -- in order to allow systems with
      enhanced security features to conform.

 Additionally, we have set the wheels in motion for
 consideration of two further activities:

    - Conformance Test.  We are suggesting that  IEEE Std
      1003.3[2] becomes an ISO standard via the fast track
      procedure.  Meanwhile, members of the Rapporteur group
      on Conformance Testing are working on a "consensus


 __________

  4. The folks responsible for OSI.

  5. So as to conform  with ISO dogma, these will be appear
     first in Language Independent form, rather than as C
     language interfaces -- see below.












                            - 4 -



      specification for a single scaffold" for testing.
      Perhaps they all want to hang together...

    - The POSIX Guide otherwise known as 1003.0, is being put
      forward by the working group as a proposed draft ISO
      technical Report.  This has to do with Open System
      Environment Profiles, the subject of the group's
      longest resolution, which consists mostly of questions
      that the group would like answered by those working on
      profiles elsewhere in ISO.

 Add all those topics together, and you have a lot of work --
 a fact that has not been lost on those who think that the
 ISO POSIX working group is getting too ambitious.  But
 that's politics, which I'm saving until the end.

                    French_Lessons_for_Ada

 In [3] I expounded at length on the issue of Language
 Independent Specifcations (LIS) -- an topic which ISO has
 hitherto thought more important than have those actually
 writing the bulk of the POSIX standards under the auspices
 of the IEEE in the USA.  Happily, early this year, the IEEE
 came up with some money to sponsor the production of first
 full drafts of two documents: a Language Independent
 Specification defining services corresponding to those set
 out in the current operating system interface standard[4];
 and a set of C language bindings to those services.  Taken
 together, these two documents should provide no advance over
 the existing standard -- as far as C programmers are
 concerned.

 So why do it?  Pour encourager les autres -- such as the
 group in New Zealand which has expressed an interest in
 defining a Modula 2 binding to POSIX services, and those
 developing a C++ standard6.  We want them to do things in
 (what we consider to be) the right way, having learned
 useful lessons at the expense of the IEEE's 1003.5 and
 1003.9 working groups, which have been working on Ada and
 FORTRAN bindings to the POSIX operating system services
 defined by the 1003.1 standard in terms of their interface
 to the C language.


 __________

  6. We have passed words of encouragement to the Modula 2
     enthusiasts, but decided to keep quiet about C++ until
     ISO makes up its mind as to where it fits in the scheme
     of things.  Politics again.












                            - 5 -



 Inevitably, a definition in the C language presumes C-isms,
 such as a fairly permissive attitude to type conversion and
 the possibility of function argument lists of variable
 length.  Such idioms do not map onto good (or, indeed,
 legal) Ada or FORTRAN, so the writers of those bindings
 standards have had to invent alternatives.  As a result, the
 services, and the detailed semantics of those services,
 accessible from the Ada and FORTRAN differ from those
 available to programmers writing in C.  At the ISO level,
 people find it almost impossible to tolerate such
 inconsistency, even if the IEEE has a rather more relaxed
 attitude.

 But the IEEE also likes the standards that it develops to
 become international standards if they can.  Last October,
 the ISO POSIX working group said that it would not work on
 moving Ada and FORTRAN bindings forward at the international
 level until they consisted only of a thin document
 describing the means by which the languages bind to a
 language-independent service definition.  The number of
 people in the world who are qualified (and motivated) to
 create such a definition can be counted on one's fingers.
 None of them had an indulgent employer who would continue to
 pay them while they did work which would get the IEEE out of
 a hole and further the cause of international
 standardization, but which would produce no immediately
 measurable commercial benefit.

 So the IEEE found the money, put the job out to competitive
 tender, and ultimately contracted with Hal Jespersen, long-
 time editor of various POSIX standards, to produce initial
 drafts.  This he did on short order, and the documents are
 already being revised in the IEEE 1003.1 working group,
 which intends to bring them to ballot early in 1992.  ([5]
 describes what ``bringing to ballot'' means.)  They have yet
 to be distributed at the ISO level, the necessary level of
 polish not having been achieved, but should reach WG15 later
 this year.

 This means that, as far as ISO is concerned, the standards
 production process is getting back on track after a period
 when it looked as if it was going to run into the sand
 because of disagreements on priorities between the US-based
 standards developers and the rest of the world.  Sadly, the
 US-based Ada community shows little sign of participating in
 this outbreak of cooperation: it is more concerned with
 getting a standard out of the door than with producing a
 standard which fits well into the ISO scheme of things.

 Fortuitously, the ISO POSIX working group has discovered
 that there are other fish in the Ada sea7 besides the IEEE











                            - 6 -



 1003.9 working group:  a group of French experts has offered
 to make an early review of the draft POSIX LIS standard,
 commenting on its suitability as a basis for an Ada binding.
 The offer was gratefully accepted.

                           Politics

 If US Ada experts persist in ignoring ISO's plans, we could
 end up with an international standard for Ada bindings to
 POSIX services which differs considerably from the US
 standard.  This would be a Bad Thing, and would raise the
 level of exasperation of those working within ISO at the
 performance of the US as a developer of standards on behalf
 of the international community.

 To date, there has been little cause for complaint with the
 progress of POSIX development by the IEEE.  Unfortunately,
 ISO experienced considerable problems with two other SC22
 projects for which the US was the development agency:
 Fortran 90 and C8.  This has made some national member
 bodies of ISO unwilling to give the US responsibility for
 the production of further standards (such as C++), and has
 given them cause to review existing projects where the US is
 the development agency.  POSIX is one of these, so we have
 to be on our best behaviour.

 Then there's history.  Before the inception of the ISO POSIX
 project, the Japanese proposed that a new Subcommittee,
 Systems Software Interfaces (SSI), should be formed to
 handle it and other projects in what was unquestionably a
 growing field.  The Japanese expressed a willingness to
 provide a secretariat for (that is, to manage) the new
 subcommittee.  Predictably, the US didn't like this idea,
 and prevailed with its view that, rather than delay
 standardization until a new SC could be set up, POSIX should
 be accommodated in the existing subcommittee handling
 computer languages -- a subcommittee for which the US
 happens to provide a secretariat.

 This spring, the Japanese, pointing to the increasing
 workload of the ISO POSIX working group, again argued in
 favour of a new SC.  The group did not agree, and threw out


 __________

  7. Nuclear-powered submarines, perhaps?

  8. See [6] for gory details -- and a plug for POSIX: "One
     Group That's Working Well".












                            - 7 -



 a proposed resolution which would have welcomed a move of
 POSIX work to a new SC, should JTC1 decide in favour of
 creating one.  Instead, we passed a resolution which said
 that we like being in the languages subcommittee, and will
 benefit from continued close communication with other
 projects under that SC.

 The original resolution was overturned not so much because
 everybody thinks that everything about the current situation
 is wonderful, but because the proposed new SC does not
 address a potentially even larger issue: that of profiles.
 Jim Isaak, convener of the ISO POSIX working group and chair
 of the IEEE Technical Committee on Operating Systems, wrote
 about profiles in [7].  Profiles list the standards, parts
 of standards, or optional additions to standards to which
 systems must conform if they are to address the needs of
 particular applications areas.  They are near to essential
 if one wants to make sense of the dozens of OSI standards.
 It seems that POSIX is moving in the same direction,
 particularly since POSIX conforming systems will need also
 to conform to other standards such as those for SQL and...
 OSI.

 A meeting prior to the main assembly in Rotterdam drafted a
 framework for future work on POSIX profiles and, equally
 importantly, for cooperation among the many bodies which are
 developing them.  But there's still much work to do.  I
 expect we'll discuss the topic again at our next meeting in
 Stockholm, Sweden, in early November:  the issue won't go
 away.  Nor will the matter of the new SC, even if some of us
 might want it to.  I'll keep you posted.































                            - 8 -




                          REFERENCES



  1. Report on ISO  POSIX Working Group, Dominic Dunlop,
     ;login:, vol. 16, no. 1 (January/February 1991)

  2. IEEE Std 1003.3:1991:  Information Technology -- Test
     Methods for Measuring Conformance to POSIX

  3. Report on ISO  POSIX Working Group, Dominic Dunlop,
     ;login:, vol. 15, no. 5 (September/October 1990)

  4. ISO/IEC 9945-1:1990 (also known as IEEE Std 1003.1):
     Information Technology -- Portable Operating System
     Interface (POSIX) -- Part 1: System Application Program
     Interface (API) [C Language]

  5. Standards Column to be Published in the EurOpen
     Newsletter, Spring 1991, Dominic Dunlop, USENET,
     comp.std.unix, vol. 22, no. 92

  6. The Standards Process Breaks Down, Jeff Moad,
     Datamation, Sept. 15 1990 (vol.36, no. 18), pages 24
     through 32.

  7. An Update on UNIX-Related Standards Activities -- POSIX
     Profiles, ;login:, vol. 16, no. 3 (May/June 1991)

--
Dominic Dunlop


Volume-Number: Volume 25, Number 39

From [e-mail]  Thu Sep 12 13:15:27 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA22336; Thu, 12 Sep 91 13:15:27 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12482; Thu, 12 Sep 91 13:15:24 -0400
Newsgroups: comp.std.unix
From: "Bob Kitzberger @midnight" <[e-mail]>
Subject: Re: The Unimplemented/Invented/Premature/Failed Standards Chart, 9/6/91
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: TeleSoft, San Diego, CA, USA
References: <[e-mail]>
Date: Thu, 12 Sep 1991 03:17:43 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Bob Kitzberger @midnight)

Shouldn't you put a big 'ol "IMHO" surrounding this table?

>``Failed'' means that many or most of the intended users of the standard
>actively avoid using it.

Hmm.. a new definition of failed that I was previously unaware of.  I
would think a more truthful header would be "Resisted".

>Name        Unimpl.    Invent.    Premature        Failed
>Ada        yes    yes    yes (OOP)        yes (c2ada)

Hmm.. Ada is being used to develop the Space Station software, the
new Air Traffic Control system, and several other of the worlds' largest
and most ambitious projects.  If this is failure, give me more of it!

And as far as 'premature' goes, sorry.  Full OOP was certainly anything but
mature when Ada was conceived, and still cannot be considered mature.  The
partial OOP that Ada gives you (i.e. encapsulation, derived types,
separation of specification and implementation, etc.) was mature at the
time that the standard was conceived, and has been succesful in many
projects.  Inheritance is still unproven in large systems -- so how can
an immature technology (OOP) indicate how a mature technology was
premature?  i.e. was OOP mature enough in the late 70's to supercede the
proven methods used in Ada?

Careful, your hidden agenda is showing.

    .Bob.
--
Bob Kitzberger               Internet : [e-mail]
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA  92121-9891  [phone] x163
------------------------------------------------------------------------------
package body Disclaimer is separate;

[ Accepted as a rebuttal only to Dan's original post.  Please take any
  discussion about OOP, Ada, or inheiritance elsewhere -- mod ]

Volume-Number: Volume 25, Number 40

From [e-mail]  Fri Sep 13 14:05:56 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA09658; Fri, 13 Sep 91 14:05:56 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02257; Fri, 13 Sep 91 14:05:53 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 13 Sep 1991 13:50:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Henry Spencer) writes:

>>A legal call to getc() on a stream with a non-readable file descriptor
>>will always result in getc() trying to read data into the buffer...

>Please cite chapter and verse of ANSI C or POSIX.1 justifying this.
>This is the heart of the problem:  the assertion assumes a specific
>implementation technique that is not required by the standards.

It follows directly from the requirement on applications to call fflush()
or a file positioning function when switching from output to input.  I
gave the derivation in my previous article.  I'm sure nobody really needs
me to quote the relevant text from ANSI 'C', but here goes anyway:

4.9.5.3 "The fopen function", paragraph 5, second sentence:

    However, output may not be directly followed by input without an
    intervening call to the fflush function or to a file positioning
    function (fseek, fsetpos, or rewind), and input may not be
    directly followed by output without an intervening call to a file
    positioning function, unless the input operation encounters
    end-of-file.

Rather than debating whether this justifies the assertion as it stands,
I would urge people who participate in POSIX.3.1 ballots to request
that the assertion be changed to clarify that there must be no data
in the buffer when the call to getc() is made.
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 41

From [e-mail]  Fri Sep 13 14:05:59 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA09710; Fri, 13 Sep 91 14:05:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02276; Fri, 13 Sep 91 14:05:56 -0400
Newsgroups: comp.std.unix
From: Donald Lewine <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Data General Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Fri, 13 Sep 1991 14:30:08 GMT
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Geoff Clare) writes:
|> A legal call to getc() on a stream with a non-readable file descriptor
|> will always result in getc() trying to read data into the buffer.

This assertion is just plain false.  Consider:
    ungetc('X',stream);
    getc(stream);
On most systems the call to getc() will not result in any access
to the file-descriptor.

In fact, my reading of ANSI C 4.9.7.11 leads me to believe that the
call to getc() MUST succeed even if the stream has a non-readable
file descriptor since one character of push is guaranteed for all
streams.


--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]


Volume-Number: Volume 25, Number 42

From [e-mail]  Fri Sep 13 17:10:57 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA24956; Fri, 13 Sep 91 17:10:57 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25621; Fri, 13 Sep 91 17:10:55 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 13 Sep 1991 19:57:54 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>Submitted-by: [e-mail] (Geoff Clare)
>It follows directly from the requirement on applications to call fflush()
>or a file positioning function when switching from output to input.

No, this is totally wrong as a "justification" for the error test.
POSIX.1 does not require that SPECIFIC errno value, nor indeed ANY
errno value, under the circumstances in question.  You're arguing
for an additional requirement in POSIX.3.1 to test for behavior
that is NOT REQUIRED of a POSIX.1-conforming implementation, just
as Henry said.


Volume-Number: Volume 25, Number 43

From [e-mail]  Sun Sep 15 23:09:23 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA10451; Sun, 15 Sep 91 23:09:23 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27591; Sun, 15 Sep 91 23:09:18 -0400
Newsgroups: comp.std.unix
From: Jim Haynes <[e-mail]>
Subject: Tape drive handling
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of California, Santa Cruz
Date: Sun, 15 Sep 1991 05:16:06 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jim Haynes)

I'm not up on what POSIX addresses, but maybe someone who is can tell
me if it addresses this point.

Way back when we put hacks in the mag tape kernel driver to introduce
the concept of "assigning" the tape drive to a UID for the duration
of use.  When the drive is assigned no other user, not even root, can
fiddle with it.  It gets deassigned by being taken offline.

Note that chown-ing the tape devices is not sufficient because the
super user can scribble on some other user's tape.  Exclusive open
is not sufficient protection because the tape might be sitting there
at load point with a write ring in it, but not open, so anybody else
can open it.
--
[e-mail]
[e-mail]

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

[ Does *anyone* address this point?  As far as I know, POSIX says nothing
  about it.  What would errno be set to?  EBUSY would be right, but it
  means something else -- although I suppose it could be overloaded,
  since EBUSY is currently meaningless for open().  -- mod ]

Volume-Number: Volume 25, Number 44

From [e-mail]  Mon Sep 16 18:13:09 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12585; Mon, 16 Sep 91 18:13:09 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12962; Mon, 16 Sep 91 18:13:06 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 16 Sep 1991 20:22:53 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>>>A legal call to getc() on a stream with a non-readable file descriptor
>>>will always result in getc() trying to read data into the buffer...
>
>>Please cite chapter and verse of ANSI C or POSIX.1 justifying this...
>
>It follows directly from the requirement on applications to call fflush()
>or a file positioning function when switching from output to input...
>I would urge people who participate in POSIX.3.1 ballots to request
>that the assertion be changed to clarify that there must be no data
>in the buffer when the call to getc() is made.

Please explain the derivation in more detail.  The requirement you cite
says that it is improper for an application to apply getc() to a stream
opened for output only, without at least doing an fflush() first.  However,
this says nothing about what getc() will then do.  For example, fflush()
imposes no requirement that the data in the buffer be marked invalid,
only that it be flushed out to disk.  How do you propose to establish
that there is "no data in the buffer"?  What does this *mean*?  Neither
ANSI C nor POSIX.1 even defines such a concept, that I know of.

Your whole argument appears to be phrased in terms of such underlying
assumptions about how the i/o library works... assumptions that cannot
be justified based on the standards themselves.  To return to the original
point, doing a getc() in these circumstances is an improper operation, but
none of the standards makes any promises about the nature of the result.
In particular, there is no guarantee of an orderly return with an error
code.
--
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  [e-mail]  utzoo!henry


Volume-Number: Volume 25, Number 45

From [e-mail]  Mon Sep 16 19:36:10 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07288; Mon, 16 Sep 91 19:36:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04217; Mon, 16 Sep 91 19:36:06 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Tape drive handling
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Mon, 16 Sep 1991 22:34:16 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Jim Haynes) writes:
>Way back when we put hacks in the mag tape kernel driver to introduce
>the concept of "assigning" the tape drive to a UID for the duration
>of use.  When the drive is assigned no other user, not even root, can
>fiddle with it.  It gets deassigned by being taken offline.
>Note that chown-ing the tape devices is not sufficient because the
>super user can scribble on some other user's tape.  Exclusive open
>is not sufficient protection because the tape might be sitting there
>at load point with a write ring in it, but not open, so anybody else
>can open it.
>[ Does *anyone* address this point?  As far as I know, POSIX says nothing
>  about it.  What would errno be set to?  EBUSY would be right, but it
>  means something else -- although I suppose it could be overloaded,
>  since EBUSY is currently meaningless for open().  -- mod ]

There is no need for a kernel-facility standard to specifically address
this, because (a) there is no established existing practice and (b) the
necessary kernel support for implementing user-mode solutions already
exists in the standard facilities.

Contrary to the claim made by Haynes, chown (by a device management
facility) is generally sufficient; protection from superuser actions
is not something to be attempted anyway.  A facility for managing such
resources can readily allocate all manner of file-like objects, not
juts tape drives.  Years ago I designed such a facility, but there has
not been enough demand for it in my environment to bother implementing
it.  The only tricky part was figuring out how to deallocate a resource
when the allocating user forgets and logs out.  (The solution was to
take care of it upon allocation attempt, which can figure out whether
or not the user is still logged in.  Allowance must be made for "daemon"
users, too, but really it's all quite straightforward.)

Volume-Number: Volume 25, Number 46

From [e-mail]  Tue Sep 17 16:47:41 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA09620; Tue, 17 Sep 91 16:47:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23190; Tue, 17 Sep 91 16:47:38 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 17 Sep 1991 17:46:28 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

In <[e-mail]> [e-mail] (Donald Lewine) writes:

>This assertion is just plain false.  Consider:
>    ungetc('X',stream);
>    getc(stream);
>On most systems the call to getc() will not result in any access
>to the file-descriptor.

My apologies, I had overlooked the use of ungetc().  A condition relating
to this needs to be added to the POSIX.3.1 assertion.

In <[e-mail]> [e-mail] (Doug Gwyn) writes:

>In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>>It follows directly from the requirement on applications to call fflush()
>>or a file positioning function when switching from output to input.

>No, this is totally wrong as a "justification" for the error test.
>POSIX.1 does not require that SPECIFIC errno value, nor indeed ANY
>errno value, under the circumstances in question.

It is the "circumstances in question" that are currently wrong, and that
I am trying to correct.  The circumstances in the test suite which
generated this thread were fp = fopen(file, "w"); getc(fp), which we
have established are incorrect.  They correspond to the POSIX.3.1 draft
11 assertion, which has been changed in draft 12 to something closer
to what is needed, but still not quite right.

There is no doubt that an EBADF assertion is required in POSIX.3.1, the
only problem is what the precise conditions necessary to generate an
EBADF are.

>You're arguing
>for an additional requirement in POSIX.3.1 to test for behavior
>that is NOT REQUIRED of a POSIX.1-conforming implementation, just
>as Henry said.

OK, lets start from the beginning and try to come up with a correct
assertion.  POSIX.1-1990 states in 8.2.3.11:

    "If any of the functions above return an error indication, the
    value of errno shall be set to indicate the error condition.
    If that error condition is one that this part of ISO/IEC 9945
    specifies to be detected by one of the corresponding underlying
    functions, the value of errno shall be the same as the value
    specified for the underlying function."

One of the "functions above" is getc() (8.2.3.5), and the underlying
functions for getc() are read() and lseek().

The error condition we are interested in is an EBADF for read(),
which is described in 6.4.1.4:

    "[EBADF]  The fildes argument is not a valid file descriptor
          open for reading."

So, the relevant requirements of POSIX.1 on getc() are that if it
returns an error indication under circumstances where the file
descriptor addressed by the stream is not open for reading, then
getc() sets errno to EBADF.

Personally, I would have thought the obvious way to write a POSIX.3.1
assertion relating to this requirement would be to state exactly the
above (altered to fit POSIX.3's assertion writing rules, of course).
I.e. retain the condition on "if getc() returns an error indication".
However, POSIX.3.1 has instead attempted to state the conditions under
which getc() will definitely return an error indication, and so I will
attempt to give a corrected version of their assertion instead:

    When the stream pointer argument addresses a file descriptor
    that is not open for reading, and there are no data in the
    stream buffer, and there has been no previous call to ungetc()
    for the stream, then a call to getc() returns a value of EOF
    and sets errno to [EBADF].

A test for this assertion could be implemented as follows:

    fp = fdopen(creat(file, mode), "w");
    getc(fp);

which is exactly what I said, in my first article, that the test suite
should be changed to do.

All happy now?
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 47

From [e-mail]  Wed Sep 18 18:21:11 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16732; Wed, 18 Sep 91 18:21:11 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16586; Wed, 18 Sep 91 18:21:05 -0400
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Re: Tape drive handling
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Auckland, New Zealand.
References: <[e-mail]>
Date: Tue, 17 Sep 1991 23:06:43 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

[e-mail] (Doug Gwyn) writes:

>In article <[e-mail]> [e-mail] (Jim Haynes) writes:
>>Way back when we put hacks in the mag tape kernel driver to introduce
>>the concept of "assigning" the tape drive to a UID for the duration
>>of use.  When the drive is assigned no other user, not even root, can
>>fiddle with it.  It gets deassigned by being taken offline.
[ stuff deleted ]
>There is no need for a kernel-facility standard to specifically address
>this, because (a) there is no established existing practice and (b) the
>necessary kernel support for implementing user-mode solutions already
>exists in the standard facilities.

>Contrary to the claim made by Haynes, chown (by a device management
>facility) is generally sufficient; protection from superuser actions
>is not something to be attempted anyway.  A facility for managing such
[stuff deleted...]

I disagree Doug. The purpose of this sort of protection it to prevent
accidental overwriting of tapes. The fact that it is root doing the
overwriting is totally irrelevant, the result is the same. Loss of data.

On our system we have two 8mm tape drives with one character difference
in their names. It is trivially easy for an operator in a hurry to reference
the wrong drive and overwrite another tape. It is not difficult to
think up scenarios where the mistake will not be noticed and permanent
data loss will result. This is why most other operating systems  have
a mechanism for assigning a resource for the exclusive use of a particular
user.

Root needs a means of detaching the resource from a user if they forget,
or if their job hangs up, but apart from that root should just be another
user with the same access privileges.

Cheers, Russell.
--
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<[e-mail]>



Volume-Number: Volume 25, Number 48

From [e-mail]  Wed Sep 18 18:21:13 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16740; Wed, 18 Sep 91 18:21:13 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16616; Wed, 18 Sep 91 18:21:08 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Sep 1991 09:38:55 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>There is no doubt that an EBADF assertion is required in POSIX.3.1, the
>only problem is what the precise conditions necessary to generate an
>EBADF are.

>    "If any of the functions above return an error indication, ...

BUT!  There is, as Henry and I keep explaining, no requirement that
getc() return an error condition even under such "obviously wrong"
conditions as your example test-suite code.  The C standard does not
specify what happens if the FILE* fed to getc() is not an input stream,
and getc() is NOT flagged with a "+" in ISO/IEC 9945-1:1990(E), where
the only additional constraint has to do with the POSIX-specific atime.
9945-1 specifically exempts getc() from having to be implemented in
terms of the "underlying functions" read() and lseek().  The clause
on error reporting that you cited requires ONLY that IF an error (of
any sort) is detected, errno be set; and if THAT error is one that
9945-1 specifies shall be detected by one of the underlying functions,
THEN the 9945-1-specified errno value shall be the one used in the
error report.  However, I would expect that getc() is free to notice
that the input stream (FILE structure) is not set for reading, i.e.
some flag member of the FILE structure does not have the (_IORONLY|
_IORANDW) bits set, and thus never even attempt the equivalent of
read(), in which case getc() is allowed to report the error by any
errno value its little heart desires; it is also NOT REQUIRED to
attempt to detect this error at all!  It is a clear case of
"undefined behavior" (in C Standard parlance), and intentionally so.
Attempting to test for what happens in a case of undefined behavior
is folly; such a test program could do literally ANYthing in a
standard conforming environment.

The reason this whole question came up in the first place is that an
EFFICIENT, traditional implementation of getc() is NOT going to be
able to reliably detect that it is being used in an undefined manner.
The standards deliberately do not require it to.  You do nobody a
favor by adding your own implementation model on top of what is
actually required, then test in terms of your model.

>However, POSIX.3.1 has instead attempted to state the conditions under
>which getc() will definitely return an error indication, and so I will
>attempt to give a corrected version of their assertion instead:
>    When the stream pointer argument addresses a file descriptor
>    that is not open for reading, and there are no data in the
>    stream buffer, and there has been no previous call to ungetc()
>    for the stream, then a call to getc() returns a value of EOF
>    and sets errno to [EBADF].

That is HORRIBLE!  Why would POSIX.3.1 be ADDING CONSTRAINTS TO
POSIX.1?  That is NOT their job, and in this case it is being badly
botched even if it WERE their job.  By golly, POSIX.3 is supposed
to be preparing test procedures for verifying conformance with the
standards AS PUBLISHED by the other 1003 subgroups, allowing ANY
(other-)standard conforming method of implementation, not inventing
new implementation constraints.

>All happy now?

Not on your tintype.


Volume-Number: Volume 25, Number 49

From [e-mail]  Wed Sep 18 18:21:20 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16783; Wed, 18 Sep 91 18:21:20 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16636; Wed, 18 Sep 91 18:21:15 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Sep 1991 18:38:35 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>>No, this is totally wrong as a "justification" for the error test.
>>POSIX.1 does not require that SPECIFIC errno value, nor indeed ANY
>>errno value, under the circumstances in question.
>
>There is no doubt that an EBADF assertion is required in POSIX.3.1, the
>only problem is what the precise conditions necessary to generate an
>EBADF are.

Geoff, you still haven't addressed the underlying problem:  where on Earth
did POSIX.3.1 *get* this requirement?  They certainly didn't get it from
POSIX.1, which makes no such demand.  Why are they trying to rewrite the
standards they are supposed to be testing?  *Why* is an EBADF assertion
required on the result of getc()?

>Personally, I would have thought the obvious way to write a POSIX.3.1
>assertion relating to this requirement would be to state exactly the
>above (altered to fit POSIX.3's assertion writing rules, of course).
>I.e. retain the condition on "if getc() returns an error indication".
>However, POSIX.3.1 has instead attempted to state the conditions under
>which getc() will definitely return an error indication...

This is precisely the basic error here:  there is *no way to do that*
based on POSIX.1.  None.  POSIX.1 deliberately left it unspecified.
POSIX.3.1 cannot require it without implicitly rewriting POSIX.1, which
it is not supposed to be doing.
--
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  [e-mail]  utzoo!henry


Volume-Number: Volume 25, Number 50

From [e-mail]  Fri Sep 20 15:06:32 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05173; Fri, 20 Sep 91 15:06:32 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05400; Fri, 20 Sep 91 15:06:29 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Tape drive handling
Message-Id: <[e-mail]>
Followup-To: comp.unix.admin
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]>
Date: Thu, 19 Sep 1991 01:08:10 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
>>... chown (by a device management
>>facility) is generally sufficient; protection from superuser actions
>>is not something to be attempted anyway...
>
>I disagree Doug. The purpose of this sort of protection it to prevent
>accidental overwriting of tapes. The fact that it is root doing the
>overwriting is totally irrelevant...
>On our system we have two 8mm tape drives with one character difference
>in their names. It is trivially easy for an operator in a hurry to reference
>the wrong drive and overwrite another tape...

Why do you let your operators run as root?  That's a very dangerous thing
to do.  All the more so because it sounds like you're letting them run
shell commands, rather than using an operator-friendly :-) shell program
to provide an interface where a one-character error isn't disastrous.

I'm afraid that what we have here is one example of a more general syndrome:
people who routinely do all manner of things as root and then complain
because they aren't protected from the consequences of mistakes.  The whole
idea of running as root is to remove most of the routine protections, to
permit emergency surgery and suchlike.  *Running as root is dangerous.*
*It should not be done routinely.*

Rather than reinventing the Unix protection system, why not use the one
that already exists?  Run such things as a normal user, reserve root for
emergencies, and the problem goes away.
--
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  [e-mail]  utzoo!henry

[ Note the Followup-To: line if you want to continue in this direction -- mod ]

Volume-Number: Volume 25, Number 51

From [e-mail]  Fri Sep 20 15:06:40 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05270; Fri, 20 Sep 91 15:06:40 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05481; Fri, 20 Sep 91 15:06:38 -0400
Xref: kithrup comp.std.unix:368 comp.unix.large:147
Newsgroups: comp.std.unix,comp.unix.large
From: Mark Wunderlich <[e-mail]>
Subject: Archiving large files
Message-Id: <[e-mail]>
Followup-To: comp.unix.large
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Mark Wunderlich <[e-mail]>
X-Submissions: [e-mail]
Organization: Supercomputer Systems Divison, Intel Corp.
Date: Thu, 19 Sep 1991 17:35:38 GMT
To: [e-mail]

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

Archiving large files >2.14GBytes.

Having noticed that classic TAR has this file size limit (using V3.2)
I am interested in how other administrators are backing up files of
this size.  Has a modified version of TAR been created in V4 that handles
larger files?  Knowing that TAR is probably not the best archive utility
to be using maybe one of you out there can share with me your large file
archiving success stories?

Does anyone know if POSIX has a definition for large file archiving?

Thanks --- wunder

[ Note the Followup-To: line in this post, as well.  Please feel free
  to discuss it here, but the topic is marginal.  -- mod ]

Volume-Number: Volume 25, Number 52

From [e-mail]  Fri Sep 20 15:06:44 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05285; Fri, 20 Sep 91 15:06:44 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05497; Fri, 20 Sep 91 15:06:40 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 20 Sep 1991 14:55:00 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Henry Spencer) writes:

>>There is no doubt that an EBADF assertion is required in POSIX.3.1, the
>>only problem is what the precise conditions necessary to generate an
>>EBADF are.

>Geoff, you still haven't addressed the underlying problem:  where on Earth
>did POSIX.3.1 *get* this requirement?  They certainly didn't get it from
>POSIX.1, which makes no such demand.  Why are they trying to rewrite the
>standards they are supposed to be testing?  *Why* is an EBADF assertion
>required on the result of getc()?

I thought I had given a pretty clear account of where the requirement
comes from in my previous article.  Here it is again:

|POSIX.1-1990 states in 8.2.3.11:
|
|    "If any of the functions above return an error indication, the
|    value of errno shall be set to indicate the error condition.
|    If that error condition is one that this part of ISO/IEC 9945
|    specifies to be detected by one of the corresponding underlying
|    functions, the value of errno shall be the same as the value
|    specified for the underlying function."
|
|One of the "functions above" is getc() (8.2.3.5), and the underlying
|functions for getc() are read() and lseek().
|
|The error condition we are interested in is an EBADF for read(),
|which is described in 6.4.1.4:
|
|    "[EBADF]  The fildes argument is not a valid file descriptor
|          open for reading."
|
|So, the relevant requirements of POSIX.1 on getc() are that if it
|returns an error indication under circumstances where the file
|descriptor addressed by the stream is not open for reading, then
|getc() sets errno to EBADF.

Every statement in POSIX.1 which makes a requirement on the implementation
must have an assertion in POSIX.3.1 relating to it.  If there were no
assertion relating to an EBADF error from getc() then the POSIX.1 text
quoted above would not be completely covered by POSIX.3.1.

The requirement is for *an* assertion relating to an EBADF error from
getc().  The existing assertion doesn't fit the requirements.  I am
trying to come up with one that does.

>>Personally, I would have thought the obvious way to write a POSIX.3.1
>>assertion relating to this requirement would be to state exactly the
>>above (altered to fit POSIX.3's assertion writing rules, of course).
>>I.e. retain the condition on "if getc() returns an error indication".
>>However, POSIX.3.1 has instead attempted to state the conditions under
>>which getc() will definitely return an error indication...

>This is precisely the basic error here:  there is *no way to do that*
>based on POSIX.1.  None.  POSIX.1 deliberately left it unspecified.
>POSIX.3.1 cannot require it without implicitly rewriting POSIX.1, which
>it is not supposed to be doing.

I agree.  I was on a hiding to nothing trying to defend the existing
assertion, or trying to come up with a corrected version in the same
vein.  Instead I will propose an assertion written "the obvious way",
as I said above.

[e-mail] (Doug Gwyn) writes:

>>There is no doubt that an EBADF assertion is required in POSIX.3.1, the
>>only problem is what the precise conditions necessary to generate an
>>EBADF are.

>>    "If any of the functions above return an error indication, ...

>BUT!  There is, as Henry and I keep explaining, no requirement that
>getc() return an error condition even under such "obviously wrong"
>conditions as your example test-suite code.  The C standard does not
>specify what happens if the FILE* fed to getc() is not an input stream,

Good point.  The new assertion will need to take account of this.

>and getc() is NOT flagged with a "+" in ISO/IEC 9945-1:1990(E), where
>the only additional constraint has to do with the POSIX-specific atime.
>9945-1 specifically exempts getc() from having to be implemented in
>terms of the "underlying functions" read() and lseek().

I am not aware of any such exemption.  Please give a pointer to the
relevant text in POSIX.1.  If this text exists, it contradicts
8.2.3.5 which states that the underlying functions for getc() are
read() and lseek(), so it would require an official interpretation
to decide which is right.

>The clause
>on error reporting that you cited requires ONLY that IF an error (of
>any sort) is detected, errno be set; and if THAT error is one that
>9945-1 specifies shall be detected by one of the underlying functions,
>THEN the 9945-1-specified errno value shall be the one used in the
>error report.  However, I would expect that getc() is free to notice
>that the input stream (FILE structure) is not set for reading, i.e.
>some flag member of the FILE structure does not have the (_IORONLY|
>_IORANDW) bits set, and thus never even attempt the equivalent of
>read(), in which case getc() is allowed to report the error by any
>errno value its little heart desires; it is also NOT REQUIRED to
>attempt to detect this error at all!  It is a clear case of
>"undefined behavior" (in C Standard parlance), and intentionally so.
>Attempting to test for what happens in a case of undefined behavior
>is folly; such a test program could do literally ANYthing in a
>standard conforming environment.

I agree.  My proposed new assertion will avoid this by specifying an
input stream.

>The reason this whole question came up in the first place is that an
>EFFICIENT, traditional implementation of getc() is NOT going to be
>able to reliably detect that it is being used in an undefined manner.
>The standards deliberately do not require it to.  You do nobody a
>favor by adding your own implementation model on top of what is
>actually required, then test in terms of your model.

That is not what I was trying to do.  I was trying to state the
conditions under which a getc() will always attempt to read from the
file descriptor, based solely on POSIX.1 (and its references to the
C standard).  I now realise this is not an achievable goal.

[Remainder of Doug's article omitted, as it no longer seems relevant.]

Here is my attempt at an assertion which derives directly from the
requirements of POSIX.1, and carefully avoids any situation in which
the C standard says the behaviour is undefined:

    When the stream pointer argument addresses a file descriptor
    that is not open for reading, and the stream is an input
    stream, and a call to getc() returns EOF, then the call
    to getc() sets errno to [EBADF].

Now it's just a matter of getting the POSIX.3.1 committee to agree...
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 53

From [e-mail]  Fri Sep 20 16:34:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07484; Fri, 20 Sep 91 16:34:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB29919; Fri, 20 Sep 91 16:34:05 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: Badly botched assertions
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 20 Sep 1991 19:59:04 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Geoff Clare) writes:
>I thought I had given a pretty clear account of where the requirement
>comes from in my previous article.  Here it is again:
>
>|POSIX.1-1990 states in 8.2.3.11:
>|
>|    "If any of the functions above return an error indication, the
       ^^
>|    value of errno shall be set to indicate the error condition.
>|    If that error condition is one that this part of ISO/IEC 9945
>|    specifies to be detected by one of the corresponding underlying
>|    functions, the value of errno shall be the same as the value
>|    specified for the underlying function."

All the assertions in Draft 12.0 of POSIX.3.1 that address this
subclause are badly broken.

Since there's a great big "If" in 8.2.3.11, there also has to
be an "If" in each related assertion, and they have to be
conditional assertions, not required base assertions (Type A of
1003.3-1991) as they are now written.

The assertion writers (including myself; no slap intended here)
should not be trying to make assertions testable by guessing
under what conditions the interfaces will generate errors.
Since there are no portable ways to provoke many of these
errors, the assertions should be extended conditional (Type D),
and conformance test suites are justified in not testing them
at all.


Thanks to whoever pointed out this problem.  The 1003.3.1
standard will be better as a result of this discussion.
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]

Volume-Number: Volume 25, Number 54

From [e-mail]  Tue Sep 24 14:07:23 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00903; Tue, 24 Sep 91 14:07:23 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23595; Tue, 24 Sep 91 14:07:13 -0400
Newsgroups: comp.std.unix
From: Fred Zlotnick <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 21 Sep 1991 17:56:18 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:

>        [ ...much omitted... ]
>>and getc() is NOT flagged with a "+" in ISO/IEC 9945-1:1990(E), where
>>the only additional constraint has to do with the POSIX-specific atime.
>>9945-1 specifically exempts getc() from having to be implemented in
>>terms of the "underlying functions" read() and lseek().
>
>I am not aware of any such exemption.  Please give a pointer to the
>relevant text in POSIX.1.  If this text exists, it contradicts
>8.2.3.5 which states that the underlying functions for getc() are
>read() and lseek(), so it would require an official interpretation
>to decide which is right.

No contradiction exists.  Clause 8.2.3, subsection 6 (lines 341-345 on page
159 of ISO/IEC 9945-1:1990) reads:

    Each function that operates on a stream is said to have zero
    or more _underlying_functions_.  This means that the stream
    function shares certain traits with the underlying functions,
    but does not require that there be any relation between the
    implementations of the stream function and its underlying
    functions.

So no requirements whatsoever are made about implementation of the stream
functions, which is entirely appropriate.  The notion of an underlying
function is just a shorthand to avoid restating (and possibly botching)
requirements for errno when an error occurs.  This occurs in section
8.2.3.11, which I believe I cited in an earlier posting.  That section
contains the crucial words "If any of the functions above [stream functions]
return an error indication, ...". That condition is the crux of this entire
discussion.

>    [ ...much more omitted... ]
>
>Here is my attempt at an assertion which derives directly from the
>requirements of POSIX.1, and carefully avoids any situation in which
>the C standard says the behaviour is undefined:
>
>    When the stream pointer argument addresses a file descriptor
>    that is not open for reading, and the stream is an input
>    stream, and a call to getc() returns EOF, then the call
>    to getc() sets errno to [EBADF].
>

As Chuck Karish points out in a later posting, this will not do.  The
assertion must be conditional.  Many of the related assertions in
1003.3.1 should also be extended (no portable way to test), but I think
that this one can be written as a conditional base (Type C) assertion:

    If the implementation of getc() returns an error when the
    stream pointer addresses a file descriptor that is not open for
    reading: When the stream pointer argument addresses a file
    descriptor that is not open for reading, and the stream is an
    input stream, and a call to getc() returns EOF, then the call
    to getc() sets errno to [EBADF].

Corrections welcome; anyone who has tried to write assertions for 1003.1
(or any other standard) knows what a difficult business it is.
----
Fred Zlotnick                       |    #include <std.disclaimer>
[e-mail]                  |    #include <brilliant.quote>
...!{uupsi,ames}!mindcrf!fred |


Volume-Number: Volume 25, Number 56

From [e-mail]  Tue Sep 24 14:07:24 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00907; Tue, 24 Sep 91 14:07:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23587; Tue, 24 Sep 91 14:07:12 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 21 Sep 1991 01:59:09 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>Every statement in POSIX.1 which makes a requirement on the implementation
>must have an assertion in POSIX.3.1 relating to it.  If there were no
>assertion relating to an EBADF error from getc() then the POSIX.1 text
>quoted above would not be completely covered by POSIX.3.1.

Not every constraint of POSIX.1 need be verifiable by a test suite.
Those that are, should be, but those that are not should be manually
verified, verified using implementation-specific (vendor-supplied)
tests, or simply left unverified.

If particular, when the standard says, in effect, "X need not happen,
but if it does happen then Y must also occur", if there is no reliable
way to determine whether or not X occurs then the entire implication
X=>Y cannot be verified.

I think there is a fundamental confusion over the difference between
compliance with the terms of a standard (or ANY specification) and
verification via a test suite.  The latter does not imply the former
and should not be asumed to do so.  Procurement contracts ought to
specify standard conformance, and the role of test suites would be
limited to providing prima facie evidence of compliance with those
requirements, but only the absence of other evidence to the contrary.

>The requirement is for *an* assertion relating to an EBADF error from
>getc().  The existing assertion doesn't fit the requirements.  I am
>trying to come up with one that does.

Henry and I have been claiming that this is not a requirement of the
standard, period.

>>9945-1 specifically exempts getc() from having to be implemented in
>>terms of the "underlying functions" read() and lseek().
>I am not aware of any such exemption.  Please give a pointer to the
>relevant text in POSIX.1.  If this text exists, it contradicts
>8.2.3.5 which states that the underlying functions for getc() are
>read() and lseek(), so it would require an official interpretation
>to decide which is right.

I left my copy of the standard at home, but I remember clearly that
at the beginning of the section the purpose of the "underlying
functions" is explained, and it is there that the standard
specifically states that implementations of the standard I/O facilities
are NOT required to actually use those functions.

The primary purpose of the "underlying functions" is to support the
notion that the standard I/O functions also affect atime/mtime in
"reasonable" ways and that a portable application accessing an object
via both streams and file descriptors ("handles") is required to take
certain measures to ensure synchronization.

>That is not what I was trying to do.  I was trying to state the
>conditions under which a getc() will always attempt to read from the
>file descriptor, based solely on POSIX.1 (and its references to the
>C standard).  I now realise this is not an achievable goal.

Well, at least we seem to have achieved that much.

>Here is my attempt at an assertion which derives directly from the
>requirements of POSIX.1, and carefully avoids any situation in which
>the C standard says the behaviour is undefined:
>    When the stream pointer argument addresses a file descriptor
>    that is not open for reading, and the stream is an input
>    stream, and a call to getc() returns EOF, then the call
>    to getc() sets errno to [EBADF].

This is still not satisfactory; there is no standard meaning for the
notion of a "stream pointer argument addressing a file descriptor";
POSIX.1-conforming implementations are possible where both streams
and file descriptors are implemented in terms of some other underlying
I/O channel primitive, for example, with the POSIX "layer" performing
requisite bookkeeping for atimes etc.  (The C environment on my home
computer is much like that.)

Even if there were a clear connection between streams and file
descriptors, how would you arrange for the stream to be valid but
its file descriptor to not be open for reading?  The only methods
I could envision for attempting that all would clearly interfere
with the implementation in ways that are not permitted to a conforming
application.

getc() can return EOF for a number of reasons other than true end of
file; for those (for which ferror() reports nonzero), errno is required
by POSIX.1 to be set (to a nonzero value), but THAT IS ALL THAT POSIX.1
GUARANTEES.  Therefore that is the maximum extent to which a universal
validation assertion can go.  Internal details of the implementation
are simply not accessible, so the POSIX.1 conditions that depend on
"IF ... happens in the implementation" are not testable.  You probably
think that it is possible to arrange so that the "..." condition WILL
reliably occur, but I dispute that -- there are many, many things that
could cause a (legitimate) error return from getc(), and you have no
way of being sure that something not rigidly covered by the standard
is not at work.

A desire on the part of POSIX.3.1 for completeness is commendable, but
not a desire for overcompleteness.  Implementations are deliberately
allowed considerable leeway by the standards, and conformance checking
should fully support that by not attempting to check error conditions
more strongly than the standards felt was important to really guarantee.

Keep in mind that UNIX and C were deliberately designed with more
generality than is actually used in any specific instance; the
additional implementation freedom is very important in this milieu.
It is a major factor in the practical success of these systems; we're
not talking about some academic crisply-delimited well-defined model.


Volume-Number: Volume 25, Number 55

From [e-mail]  Tue Sep 24 14:07:26 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00916; Tue, 24 Sep 91 14:07:26 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB23613; Tue, 24 Sep 91 14:07:17 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 23 Sep 1991 18:13:51 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Chuck Karish) writes:

>>|POSIX.1-1990 states in 8.2.3.11:
>>|
>>|    "If any of the functions above return an error indication, the
>       ^^
>>|    value of errno shall be set to indicate the error condition.
>>|    If that error condition is one that this part of ISO/IEC 9945
>>|    specifies to be detected by one of the corresponding underlying
>>|    functions, the value of errno shall be the same as the value
>>|    specified for the underlying function."

>All the assertions in Draft 12.0 of POSIX.3.1 that address this
>subclause are badly broken.

>Since there's a great big "If" in 8.2.3.11, there also has to
>be an "If" in each related assertion, and they have to be
>conditional assertions, not required base assertions (Type A of
>1003.3-1991) as they are now written.

Wrong.  An "if" in POSIX.1 does not automatically mean there has to be
an "if" in POSIX.3.1.  In POSIX.3.n, "if" has a very specific use: it
introduces assertions which are conditional upon optional features.
The "if" in question does not relate to an optional feature.

Chuck is confusing two common occurrences in POSIX.1, exemplified by
the "Errors" section for fork(), 3.1.1.4.  It states:

    "If any of the following conditions occur, the fork() function shall
    return -1 and set errno to the corresponding value:

    [EAGAIN]   ...

    For each of the following conditions, if the condition is detected,
    the fork() function shall return -1 and set errno to the corresponding
    value:

    [ENOMEM]   ..."


Detection of ENOMEM is optional, but detection of EAGAIN is not (despite
the "great big If").  Detection of errors from stream I/O functions is
only optional if the error condition is specified as optional for the
underlying function, as for the fork() ENOMEM error above.  That is not
the case for a read() EBADF error.

>The assertion writers (including myself; no slap intended here)
>should not be trying to make assertions testable by guessing
>under what conditions the interfaces will generate errors.
>Since there are no portable ways to provoke many of these
>errors, the assertions should be extended conditional (Type D),
>and conformance test suites are justified in not testing them
>at all.

If there are no portable ways to provoke the state conditions of a
given assertion, the assertion is classified as extended - type D if
the assertion is also conditional, otherwise type B.  In the case of
getc() and EBADF there is no option feature involved, so if the assertion
were untestable it would be classified as type B, not type D as Chuck
says.  However, I don't believe it is untestable.  The following sequence
of calls is a portable method of provoking the error:

    fp = fopen(file, "r");
    close(fileno(fp));
    getc(fp);

If anyone can find fault with that test method, I would like to hear
about it, because that is exactly what I used when I wrote a test for
this assertion as part of the X/Open verification suite.  The code has
been used to test hundreds of different systems over the last three
years, and I have not had any complaints.

>Thanks to whoever pointed out this problem.  The 1003.3.1
>standard will be better as a result of this discussion.

Yes, indeed.  If only there was this level of detailed discussion of all
assertions, then 1003.3.1 could be a very good standard.  As it is, most
balloters seem to have lost interest.  I produced hundreds of objections
to draft 12, many of them correcting glaringly obvious errors (and all
but a few were accepted).  Yet many of the balloters voted to approve
draft 12!
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 57

From [e-mail]  Tue Sep 24 14:07:30 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00921; Tue, 24 Sep 91 14:07:30 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23630; Tue, 24 Sep 91 14:07:21 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: testability
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 24 Sep 1991 00:22:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail]
(Doug Gwyn) writes:
>In article <[e-mail]> [e-mail]
>(Geoff Clare) writes:
>>Every statement in POSIX.1 which makes a requirement on the implementation
>>must have an assertion in POSIX.3.1 relating to it.  If there were no
>>assertion relating to an EBADF error from getc() then the POSIX.1 text
>>quoted above would not be completely covered by POSIX.3.1.
>
>Not every constraint of POSIX.1 need be verifiable by a test suite.

Everyone involved in writing assertions should understand this.
It's spelled out pretty clearly in the 1003.3 standard.

See the definition of an "extended assertion" in Section 5
of 1003.1.  Tests for such assertions may return FAIL
on systems where it is possible to detect a problem, and
UNTESTED on systems where it is not.
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]


Volume-Number: Volume 25, Number 58

From [e-mail]  Tue Sep 24 14:07:36 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00926; Tue, 24 Sep 91 14:07:36 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23645; Tue, 24 Sep 91 14:07:23 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: More on "If"
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 24 Sep 1991 02:04:36 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail]
(Geoff Clare) writes:
>
>[e-mail] (Chuck Karish) writes:
>
>>Since there's a great big "If" in 8.2.3.11, there also has to
>>be an "If" in each related assertion, and they have to be
>>conditional assertions, not required base assertions (Type A of
>>1003.3-1991) as they are now written.
>
>Wrong.  An "if" in POSIX.1 does not automatically mean there has to be
>an "if" in POSIX.3.1.  In POSIX.3.n, "if" has a very specific use: it
>introduces assertions which are conditional upon optional features.
>The "if" in question does not relate to an optional feature.
>
>Chuck is confusing two common occurrences in POSIX.1, exemplified by
>the "Errors" section for fork(), 3.1.1.4.  It states:

[ counterexample elided ]

Geoff's counterexample to the notion that every "If" in POSIX.1
requires an "If" in 1003.3.1 is correct; I overstated this point.
I stand by my interpretation that this particular "If" has to be
answered with a corresponding "If".

>If there are no portable ways to provoke the state conditions of a
>given assertion, the assertion is classified as extended - type D if
>the assertion is also conditional, otherwise type B.  In the case of
>getc() and EBADF there is no option feature involved, so if the assertion
>were untestable it would be classified as type B, not type D as Chuck
>says.

This isn't what 1003.3 says.  The definition of a conditional
feature (subclause 2.2.2.5) is

    A feature or behavior referred to in a POSIX standard that
    need not be present on all conforming implementations.

The word "if" in 1003.3.x assertions is reserved for conditional
assertions, whether or not they refer to specially declared
options in the base standard.

Having getc() return EOF, [EBADF] is a behavior that need not
be present on all conforming POSIX.1 implementations.


Geoff seems to be focusing on the second sentence of 8.2.3.11
and missing the fact that it's qualified by the first
sentence (Reader beware: this subclause was changed between
the 1988 and 1990 standards, presumably for the sake of
clarity ;-).

I can't find a requirement anywhere in the C standard or in
POSIX.1 that a stream function must ever return an error
indicator.  8.2.3 (6) says that

    "the stream function shares certain traits with the
    underlying functions..."

The only subclause in 1003.1 that spells out such traits is
8.2.3.11, which specifies, in a conditional manner, the
handling of errors.

>If there are no portable ways to provoke the state conditions of a
>given assertion, the assertion is classified as extended - type D if
>the assertion is also conditional, otherwise type B.  In the case of
>getc() and EBADF there is no option feature involved, so if the assertion
>were untestable it would be classified as type B, not type D as Chuck
>says.  However, I don't believe it is untestable.  The following sequence
>of calls is a portable method of provoking the error:
>
>    fp = fopen(file, "r");
>    close(fileno(fp));
>    getc(fp);
>
>If anyone can find fault with that test method, I would like to hear
>about it, because that is exactly what I used when I wrote a test for
>this assertion as part of the X/Open verification suite.  The code has
>been used to test hundreds of different systems over the last three
>years, and I have not had any complaints.

This looks like a good test method.  That makes this a type C
assertion.  Remember that it's not testing something that's
required by 1003.1; there's no requirement that the system
report an error.  The test outcome must be UNSUPPORTED if the
implementation does not return an error indicator when the
quoted code is executed.

I'd like to see all the assertions in 1003.3.1 that refer to
error conditions re-worded to be conditional with respect to
whether the system returns the respective errors, and their
types (A, B, C, D) re-examined.  There are other problems in
the descriptions of stream functions; in particular, "file
descriptor that is associated with a stream" (see
11.7.2.fclose(), assertion 4) is not an adequate way to
describe the behavior of an open file description that's
accessed by both types of handles.
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]


Volume-Number: Volume 25, Number 59

From [e-mail]  Tue Sep 24 14:14:41 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01452; Tue, 24 Sep 91 14:14:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26481; Tue, 24 Sep 91 14:14:32 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: Error in my analysis
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 24 Sep 1991 03:26:59 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Chuck Karish) writes:
>I can't find a requirement anywhere in the C standard or in
>POSIX.1 that a stream function must ever return an error
>indicator.

Of course, this is wrong.  The C standard specifies that
functions return EOF under some conditions.

A POSIX.1 implementation that claims Common-Usage C
Language-Dependent System Support need not return such errors
if this behavior is documented in the POSIX Conformance
Document.

Taken literally, subclause 1.3.3.3 of POSIX.1 would seem to
make all assertions that refer to subclause 8.1 conditional on
whether the system claims C Standard Language-Dependent System
Support or claims Common-Usage Language-Dependent System
Support and supports the feature referenced by the assertion.

Once again, the spirit of WEIRDnix prevails over the common
wisdom.
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]


Volume-Number: Volume 25, Number 60

From [e-mail]  Thu Sep 26 15:05:23 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22210; Thu, 26 Sep 91 15:05:23 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05483; Thu, 26 Sep 91 15:02:31 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 26 Sep 1991 13:03:36 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Doug Gwyn) writes:

>>The requirement is for *an* assertion relating to an EBADF error from
>>getc().  The existing assertion doesn't fit the requirements.  I am
>>trying to come up with one that does.

>Henry and I have been claiming that this is not a requirement of the
>standard, period.

Well Doug has, but I haven't seen Henry re-affirm that claim since my
article explaining where the requirement comes from.

>>>9945-1 specifically exempts getc() from having to be implemented in
>>>terms of the "underlying functions" read() and lseek().
>>I am not aware of any such exemption.  Please give a pointer to the
>>relevant text in POSIX.1.  If this text exists, it contradicts
>>8.2.3.5 which states that the underlying functions for getc() are
>>read() and lseek(), so it would require an official interpretation
>>to decide which is right.

>I left my copy of the standard at home, but I remember clearly that
>at the beginning of the section the purpose of the "underlying
>functions" is explained, and it is there that the standard
>specifically states that implementations of the standard I/O facilities
>are NOT required to actually use those functions.

Sorry, this was a misunderstanding on my part.  I thought Doug was
referring to some specific exemption for getc() here, which is why I
queried it.  He is, of course, correct to say that getc(), just like all
the stream I/O functions, doesn't have to actually call its underlying
functions.  I never said it did.

>The primary purpose of the "underlying functions" is to support the
>notion that the standard I/O functions also affect atime/mtime in
>"reasonable" ways and that a portable application accessing an object
>via both streams and file descriptors ("handles") is required to take
>certain measures to ensure synchronization.

I am not aware of any text in POSIX.1-1990 which directly relates
timestamps to the idea of underlying functions.  Even if there is, it
is manifestly not the "primary purpose" of underlying functions, since
the standard makes explicit statements about the updating of timestamps
for each stream I/O function.

The primary purpose of the "underlying functions" is to ensure that
errno is set appropriately for POSIX.1-defined error conditions.

>>    When the stream pointer argument addresses a file descriptor
>>    that is not open for reading, and the stream is an input
>>    stream, and a call to getc() returns EOF, then the call
>>    to getc() sets errno to [EBADF].

>This is still not satisfactory; there is no standard meaning for the
>notion of a "stream pointer argument addressing a file descriptor";

Doug may have a point about the word "addresses".  However, the
relationship between file descriptors and streams is perfectly clear.
See 8.2.1.2:

    "The fileno() function returns the integer file descriptor
    associated with the stream (see 5.3.1)."

>Even if there were a clear connection between streams and file
>descriptors, how would you arrange for the stream to be valid but
>its file descriptor to not be open for reading?

There are two obvious ways.  I gave one in my last article:

    fp = fopen(file, "r");
    close(fileno(fp));

The other is:

    fp = fopen(file1, "r");
    fd = creat(file2, mode);
    dup2(fd, fileno(fp));

>getc() can return EOF for a number of reasons other than true end of
>file; for those (for which ferror() reports nonzero), errno is required
>by POSIX.1 to be set (to a nonzero value), but THAT IS ALL THAT POSIX.1
>GUARANTEES.

Wrong.  It also guarantees that in cases where the error condition is one
that is specified to be detected by the underlying functions read() or
lseek() then the value that errno has been set to will be the same as the
value specified for the underlying function.

>Therefore that is the maximum extent to which a universal
>validation assertion can go.  Internal details of the implementation
>are simply not accessible, so the POSIX.1 conditions that depend on
>"IF ... happens in the implementation" are not testable.  You probably
>think that it is possible to arrange so that the "..." condition WILL
>reliably occur, but I dispute that -- there are many, many things that
>could cause a (legitimate) error return from getc(), and you have no
>way of being sure that something not rigidly covered by the standard
>is not at work.

This is a minor point.  The only difference whether or not the error
condition can be reliably produced makes is whether the assertion is
classified as type A or B.  The text of the assertion is the same in
either case.

--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 61

From [e-mail]  Thu Sep 26 15:05:24 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22211; Thu, 26 Sep 91 15:05:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05511; Thu, 26 Sep 91 15:02:33 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 26 Sep 1991 13:20:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Chuck Karish) writes:

>Having getc() return EOF, [EBADF] is a behavior that need not
>be present on all conforming POSIX.1 implementations.

>Geoff seems to be focusing on the second sentence of 8.2.3.11
>and missing the fact that it's qualified by the first
>sentence (Reader beware: this subclause was changed between
>the 1988 and 1990 standards, presumably for the sake of
>clarity ;-).

The first sentence (in POSIX.1-1990) is:

    "If any of the functions above return an error indication, the
    value of errno shall be set to indicate the error condition."

This is a statement of mandatory behaviour required in the case where
a call to a function returns an error indication.  I cannot see any way
in which this could be interpreted as describing optional behaviour.

>I'd like to see all the assertions in 1003.3.1 that refer to
>error conditions re-worded to be conditional with respect to
>whether the system returns the respective errors, and their
>types (A, B, C, D) re-examined.

This is utterly ludicrous.  If error detection were always optional
why would POSIX.1 state specifically that, for example, detection of
ENOMEM by fork() is optional?

If Chuck's suggestion were adopted, it would mean that a system which
doesn't return -1 and set errno to EBADF when you call read(-1, buf, n)
could be called POSIX conformant.  That's ridiculous!
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 62

From [e-mail]  Fri Sep 27 20:01:12 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26343; Fri, 27 Sep 91 20:01:12 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16998; Fri, 27 Sep 91 20:01:01 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 27 Sep 1991 11:55:58 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>Wrong.  It also guarantees that in cases where the error condition is one
>that is specified to be detected by the underlying functions read() or
>lseek() then the value that errno has been set to will be the same as the
>value specified for the underlying function.

And it also does NOT insist that any SPECIFIC invocation of getc()
attempt to perform the underlying function using the associated
file descriptor.

I don't think Geoff is going to change his mind.  The bottom line
that I wish to emphasize is that no fully conforming program can
adequately validate that an implementation conforms to the spec in
question, because in order to do so some assumptions about the
implementation BEYOND what is stated in the standard(s) must be made.


Volume-Number: Volume 25, Number 63

From [e-mail]  Fri Sep 27 20:01:15 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26352; Fri, 27 Sep 91 20:01:15 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17005; Fri, 27 Sep 91 20:01:05 -0400
Newsgroups: comp.std.unix
From: Michael I Bushnell <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Free Software Foundation, Cambridge, MA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 27 Sep 1991 20:25:05 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:

   If Chuck's suggestion were adopted, it would mean that a system which
   doesn't return -1 and set errno to EBADF when you call read(-1, buf, n)
   could be called POSIX conformant.  That's ridiculous!

Do people actually write programs which depend on this?  This, IMHO,
is a major problem with the approach taken by the Posix committees.  I
can think of half a dozen nifty extensions which would use negative
file descriptors.  The standard *should* say that the effects of
negative file descriptors are undefined, and guarantee that relevant
functions (like open and creat) will never return negative file
descriptors.

    -mib


Volume-Number: Volume 25, Number 64

From [e-mail]  Sun Sep 29 03:00:16 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18943; Sun, 29 Sep 91 03:00:16 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25616; Sun, 29 Sep 91 03:00:13 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 29 Sep 1991 00:54:00 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>>Henry and I have been claiming that this is not a requirement of the
>>standard, period.
>
>Well Doug has, but I haven't seen Henry re-affirm that claim since my
>article explaining where the requirement comes from.

Henry has just a few other things to do. :-)  However, Henry's opinion
remains unchanged:  the requirement contains an important "if", the
proposed assertions do not, and the assertions are therefore wrong.
The "if" condition is of a particularly awkward kind, in that no way is
provided to evaluate it automatically, but that does not make it go
away -- 1003.3.1 cannot replace it with something easier to evaluate,
and certainly cannot replace it with "if (1)", however convenient that
might be.
--
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  [e-mail]  utzoo!henry

Volume-Number: Volume 25, Number 65

From [e-mail]  Mon Sep 30 03:14:10 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20702; Mon, 30 Sep 91 03:14:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11381; Mon, 30 Sep 91 03:14:07 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: When does "if" mean "when", and when does it mean "if"?
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 30 Sep 1991 03:45:25 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Geoff Clare) writes:
>[e-mail] (Chuck Karish) writes:
>
>>Having getc() return EOF, [EBADF] is a behavior that need not
>>be present on all conforming POSIX.1 implementations.
>
>>Geoff seems to be focusing on the second sentence of 8.2.3.11
>>and missing the fact that it's qualified by the first
>>sentence.
>
>The first sentence (in POSIX.1-1990) is:
>
>    "If any of the functions above return an error indication, the
>    value of errno shall be set to indicate the error condition."
>
>This is a statement of mandatory behaviour required in the case where
>a call to a function returns an error indication.  I cannot see any way
>in which this could be interpreted as describing optional behaviour.

I find it quite frustrating that a sentence that seems to
be perfectly clear to all of us is actually being
interpreted in two different ways.

Much confusion seems to exist in the 1003.3.1 committee
over the meaning of the word "if".  In some cases it's
interpreted to mean "Under circumstances where the
implementation encounters the following situation..."
(sometimes changed to "when" in the 1003.3.1 assertions),
and in other cases it's interpreted in the sense of "Some
implementations may support this behavior and some may
not."

I find it to be unequivocally clear that the 1003.1
committee meant this "if" to mean "if under this
implementation the function returns an error ...".  This
defines optional behavior.

For confirmation, see the rationale for 8.2.3.11:

    POSIX.1 intentionally does not require that all errors
    detected by the underlying functions be detected by the
    functions listed here.  There are many reasonable cases
    where this might not occur; for example, many of the
    functions with write() as an underlying function might
    not detect a number of error conditions in cases where
    they simply buffer output for a subsequent flush.

We could ask 1003.1 for an interpretation, but I can't
imagine how they could have been more clear.

>>I'd like to see all the assertions in 1003.3.1 that refer to
>>error conditions re-worded to be conditional with respect to
>>whether the system returns the respective errors, and their
>>types (A, B, C, D) re-examined.
>
>This is utterly ludicrous.  If error detection were always optional
>why would POSIX.1 state specifically that, for example, detection of
>ENOMEM by fork() is optional?

My mistake.  I meant to restrict this paragraph to interfaces
described by reference to the C Standard: those listed in
8.1 and 8.2.3 of POSIX.1.

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


Volume-Number: Volume 25, Number 66

From [e-mail]  Mon Sep 30 16:25:40 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12633; Mon, 30 Sep 91 16:25:40 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07220; Mon, 30 Sep 91 16:25:32 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 30 Sep 1991 17:49:14 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Doug Gwyn) writes:

>>Wrong.  It also guarantees that in cases where the error condition is one
>>that is specified to be detected by the underlying functions read() or
>>lseek() then the value that errno has been set to will be the same as the
>>value specified for the underlying function.

>And it also does NOT insist that any SPECIFIC invocation of getc()
>attempt to perform the underlying function using the associated
>file descriptor.

This point is not being contested.  My proposed assertion does not
require getc() to return an error indication, it contains a condition on
getc() having returned an error indication.  I.e. the attempt to perform
the underlying function is effectively a state condition of the assertion.

>I don't think Geoff is going to change his mind.  The bottom line
>that I wish to emphasize is that no fully conforming program can
>adequately validate that an implementation conforms to the spec in
>question, because in order to do so some assumptions about the
>implementation BEYOND what is stated in the standard(s) must be made.

As I said before, this only affects whether or not the assertion is
classified as base or extended.  It does not affect the wording of the
assertion.  There's no point in arguing about classification until the
wording of the assertion has been agreed.

[e-mail] (Henry Spencer) writes:

>>Well Doug has, but I haven't seen Henry re-affirm that claim since my
>>article explaining where the requirement comes from.

>Henry has just a few other things to do. :-)  However, Henry's opinion
>remains unchanged:  the requirement contains an important "if", the
>proposed assertions do not, and the assertions are therefore wrong.

This demonstrates a basic lack of understanding of the precise meaning
of "if" in POSIX.3.n assertions.  The word does not have the same meaning
as it does in POSIX.1.  Some uses of "if" in POSIX.1 correspond to "if"
in POSIX.3.1, but some correspond to "when".  Which one is used depends
on whether the "if" in POSIX.1 introduces an "implementation condition"
(i.e. an optional feature, like job control being supported, or whether
fork() detects ENOMEM) or a "state condition" (e.g. whether a file
descriptor to be used in the test is readable).  In POSIX.3.1 "if" is
only used in one precise situation: to introduce the implementation
condition of a conditional assertion (classified C or D).  For state
conditions, "when" is used.

It's a shame that POSIX.1 does not contain the same precise distinction
between "if" and "when".  It would save a lot of misunderstandings.

>The "if" condition is of a particularly awkward kind, in that no way is
>provided to evaluate it automatically, but that does not make it go
>away -- 1003.3.1 cannot replace it with something easier to evaluate,
>and certainly cannot replace it with "if (1)", however convenient that
>might be.

I take it that Henry agrees with Chuck that the "if" in question
introduces an implementation condition.  If it is a state condition,
as I believe, then the automatic evaluation is simply this:

    if (getc(fp) == EOF && ferror(fp))

Only the IEEE POSIX.1 interpretations committee can decide whether this
particular "if" denotes an optional feature.  In the absence of an
official interpretation, we will have to agree to differ.
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 67

From [e-mail]  Mon Sep 30 19:03:16 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24539; Mon, 30 Sep 91 19:03:16 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18804; Mon, 30 Sep 91 19:03:05 -0400
Newsgroups: comp.std.unix
From: Michael I Bushnell <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Free Software Foundation, Cambridge, MA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 30 Sep 1991 21:04:50 GMT
Reply-To: [e-mail]
To: [e-mail]

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

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

   In article <[e-mail]> [e-mail]
   (Chuck Karish) writes:
   >I can't find a requirement anywhere in the C standard or in
   >POSIX.1 that a stream function must ever return an error
   >indicator.

   Of course, this is wrong.  The C standard specifies that
   functions return EOF under some conditions.

I'm going to focus in this post on the following (proposed) validation
routine:

   foo = fopen (..., "r");
   close (fileno (foo));
   getc (foo);

The question appears to be, Does the standard require the getc to
return EOF?  And, if getc returns EOF, what is errno?

ANSI says (4.9.7.5):
  If the stream is at end-of-file, the end-of-file indicator for the
  stream is set and getc returms EOF.  If a read error occurs, the
  error indicator for the stream is set and getc returns EOF.

The stream in the example has certainly not reached end-of-file by
either the ANSI C or Posix definitions.  Has a read error occurred?
ANSI C doesn't say, naturally.  Neither does Posix.  Nothing in
8.2.3.5 says anything about errors.  8.2.3.11 only describes how errno
is set *if* an error is returned.  Since an error is not required by
Posix or ANSI, the answer to the first question is "no".

But, if we do get an error, which do we get?  In particular, are we
guaranteed EBADF?  The answer is (6.4.1.4), we could get any of EBADF,
EINTR, or EIO.  But then, the discussion in 2.4 says that there might
be error conditions caught before checking those three.  So, in the
last analysis, we could get any error at all, but whatever we do get
must be meaningful for read (or lseek).

Why does this matter?  Why not require (and test for) the "obvious"
implementation?  The GNU system will implement both file descriptors
and streams on top of a lower level abstraction, ports.  The port
interface supports directly mapped IO, among other things.  The test
above does the following in our system:

  allocate port to file
  allocate file descriptor to file (does a sort of "dup" on the port)
  close file descriptor
  get character (successfully)

This is quite natural.  By NOT having stdio go through read, et al, it
is able to take advantage of the superior speed provided by the port
interface.

    -mib

Volume-Number: Volume 25, Number 68

From [e-mail]  Mon Sep 30 21:09:42 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28447; Mon, 30 Sep 91 21:09:42 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12882; Mon, 30 Sep 91 21:09:31 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 30 Sep 1991 23:02:20 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Geoff Clare) writes:
>    if (getc(fp) == EOF && ferror(fp))

Still useless, because the condition that the error be due to one of the
situations for which errors are specified for the underlying functions


[ Some parts of this discussion are probably better suited to
  comp.{lang,std}.c and/or comp.unix.programmer -- mod ]

Volume-Number: Volume 25, Number 69

From [e-mail]  Tue Oct  1 21:11:01 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04768; Tue, 1 Oct 91 21:11:01 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29630; Tue, 1 Oct 91 21:10:49 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 1 Oct 1991 17:03:26 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Chuck Karish) writes:

>>    "If any of the functions above return an error indication, the
>>    value of errno shall be set to indicate the error condition."

>I find it to be unequivocally clear that the 1003.1
>committee meant this "if" to mean "if under this
>implementation the function returns an error ...".  This
>defines optional behavior.

>For confirmation, see the rationale for 8.2.3.11:

>    POSIX.1 intentionally does not require that all errors
>    detected by the underlying functions be detected by the
>    functions listed here.  There are many reasonable cases
>    where this might not occur; for example, many of the
>    functions with write() as an underlying function might
>    not detect a number of error conditions in cases where
>    they simply buffer output for a subsequent flush.

The rationale refers to "cases where this might not occur" and "in
cases where they simply buffer output".  I.e. in some situations the
function might return the error indication and in others it might not.
This supports my viewpoint that the "if" introduces a state condition,
not an implementation condition.

There is definitely a state condition at work here.  The question is
whether there is a state condition AND an implementation condition.
To see this imagine for a moment that detection of the error condition
is optional.  On implementations where the condition is detected, it
still is not required to be detected by all calls to the function, only
calls made in certain situations (e.g. only when the call causes a buffer
to be filled or flushed).  So the state condition is still there in
addition to the implementation condition.

Having established that there is always a state condition, I claim that
there cannot also be an implementation condition.  If there were, then
POSIX.1 would contain two "if"s, but there is only one.

Also, it seems to me that since there is a state condition on whether
the particular call made by the test returns an error, a separate
implementation condition on whether the function detects the error
condition is redundant.  If the error condition is not detected, then
the particular call will not return an error indication, so the
implementation condition is already being catered for.
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 70

From [e-mail]  Thu Oct  3 06:51:00 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22148; Thu, 3 Oct 91 06:51:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12804; Thu, 3 Oct 91 06:50:42 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Summary: streams and file descriptors
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]>
Date: Wed, 2 Oct 1991 17:12:47 GMT
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail]
(Michael I Bushnell) writes:
>I'm going to focus in this post on the following (proposed) validation
>routine:
>
>   foo = fopen (..., "r");
>   close (fileno (foo));
>   getc (foo);
>
>The question appears to be, Does the standard require the getc to
>return EOF?

(No.)

>And, if getc returns EOF, what is errno?

>In particular, are we
>guaranteed EBADF?  The answer is (6.4.1.4), we could get any of EBADF,
>EINTR, or EIO.

I don't think so.  8.2.3.11 says that errno has to be set to
the value that would be required if write() were to fail
because of a bad file descriptor.  We are guaranteed to get
[EBADF].

>But then, the discussion in 2.4 says that there might
>be error conditions caught before checking those three.  So, in the
>last analysis, we could get any error at all, but whatever we do get
>must be meaningful for read (or lseek).
>
>Why does this matter?  Why not require (and test for) the "obvious"
>implementation?  The GNU system will implement both file descriptors
>and streams on top of a lower level abstraction, ports.  The port
>interface supports directly mapped IO, among other things.
>above does the following in our system:

  ( ... )

>This is quite natural.  By NOT having stdio go through read, et al, it
>is able to take advantage of the superior speed provided by the port
>interface.

The intention of the POSIX standards process is to avoid
imposing unnecessary restrictions on how implementors achieve
the specified functionality.  Much of 1003.1's description of
the behavior of stream-using functions is, however, done with
the implicit assumption that streams will be implemented atop
POSIX.1 low-level IO (read() and write()).

While 8.2.3 provides a reasonably clean abstraction using the
concept of an "open file description" which can be accessed
either through a file descriptor or through a stream, there are
at least half a dozen places in the standard where there is
reference to the "file descriptor associated with a stream".

The 1003.1 committees should make it clear whether it is
intended that streams must be implemented using file
descriptors.  If the answer is "yes", the most straightforward
way to do this would be to provide a POSIX definition of
"stream" in Section 2.  If the answer is "no", they must clear
up the meaning of the shorthand terminology by which it's
implied that a stream has an associated file descriptor.

Bear in mind that there's likely to be considerable resistance
to removing the assumption that streams are built on POSIX
low-level I/O (read() and write()).  This would require at least
special treatment for the file descriptors associated with the
standard streams (stdin, stdout, stderr) and some sort of
convention or documentation requirement about how streams are
handled; for example, what is the next available file
descriptor after a stream has been fopen()ed or fclose()d?

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


Volume-Number: Volume 25, Number 71

From [e-mail]  Sun Oct  6 01:14:26 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21844; Sun, 6 Oct 91 01:14:26 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06080; Sun, 6 Oct 91 01:14:24 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Sender: "Sean Eric Fagan - comp.std.unix" <[e-mail]>
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 4 Oct 1991 12:35:27 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Doug Gwyn) writes:

>>    if (getc(fp) == EOF && ferror(fp))

>Still useless, because the condition that the error be due to one of the
>situations for which errors are specified for the underlying functions

Obviously the code above would be used after the particular error condition
to be tested has been set up.  If there is no portable way to set up the
required error condition such that no other error condition could occur,
then the assertion should be classified as extended.  In the case of

    fp = fopen(file, "r");
    close(fileno(fp));

being used to set up the error condition, I can't see any other error
condition that could occur, so I believe the getc-EBADF assertion should
not be classified as extended.
--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 25, Number 72

From [e-mail]  Mon Oct  7 15:18:34 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23233; Mon, 7 Oct 91 15:18:34 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04141; Mon, 7 Oct 91 15:18:23 -0400
Newsgroups: comp.std.unix
From: Bob Lenk <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Sender: "Sean Eric Fagan - comp.std.unix" <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Mon, 7 Oct 1991 18:34:49 GMT
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Geoff Clare) writes:

> There is definitely a state condition at work here.  The question is
> whether there is a state condition AND an implementation condition.
> To see this imagine for a moment that detection of the error condition
> is optional.  On implementations where the condition is detected, it
> still is not required to be detected by all calls to the function, only
> calls made in certain situations (e.g. only when the call causes a buffer
> to be filled or flushed).  So the state condition is still there in
> addition to the implementation condition.

It could be considered a state condition, without any requirement that
any implementation ever be in one state or the other.  That means that
a test writer who wants to test this point needs to consider whether any
given test method is ever appropriate for a given implementation -
effectively an implementation condition.

> Having established that there is always a state condition, I claim that
> there cannot also be an implementation condition.  If there were, then
> POSIX.1 would contain two "if"s, but there is only one.
>
> Also, it seems to me that since there is a state condition on whether
> the particular call made by the test returns an error, a separate
> implementation condition on whether the function detects the error
> condition is redundant.  If the error condition is not detected, then
> the particular call will not return an error indication, so the
> implementation condition is already being catered for.

Exactly.  That is why POSIX.1 does not require two "if"s.  POSIX.3.1
probably requires an "if" and a "when", because its "when" clauses
must describe conditions that can be reliably reached:

    POSIX.1:    if P, Q
    POSIX.3.1:    if P is ever true: when P, Q

        Bob Lenk ([e-mail])


Volume-Number: Volume 25, Number 73

From [e-mail]  Tue Oct  8 21:09:25 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22836; Tue, 8 Oct 91 21:09:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14465; Tue, 8 Oct 91 21:09:14 -0400
From: Robin O'Neill <[e-mail]>
Newsgroups: comp.std.unix
Subject: What is the schedule for 1003.3.1?
Keywords: POSIX 1003.3 POSIX.3 POSIX.3.1
Message-Id: <[e-mail]>
Sender: UseNet News <[e-mail]>
Organization: Sequent Computer Systems, Inc.
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 8 Oct 91 21:02:12 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Robin O'Neill)

Can anyone send me the schedule of the POSIX.3.1 test assertions?
This should be the test assertions associated with the latest
approved POSIX.1-1990.  I.e., what is the current draft number?
When does it go to ballot?  Is it in ballot already?  If so, which round
and when is the anticipated approval date?

Thanks for any info,
-rto-

-------------------------------------------------------------------------------
Robin T. O'Neill                    uucp:  uunet!sequent!rto
Sequent Computer Systems, Inc.            internet:  [e-mail]
Mail Stop DES2-741               telephone:  [phone]
15450 S.W. Koll Parkway                wireless:  N7QPG (2m FM 147.04MHz)
Beaverton, Oregon  97006-6063           in-person:  Hey You


Volume-Number: Volume 25, Number 74

From [e-mail]  Wed Oct  9 16:21:50 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08921; Wed, 9 Oct 91 16:21:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05218; Wed, 9 Oct 91 16:21:29 -0400
From: Geoff Clare <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Error detection
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: UseNet News <[e-mail]>
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 9 Oct 91 15:45:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Bob Lenk) writes:

>Exactly.  That is why POSIX.1 does not require two "if"s.  POSIX.3.1
>probably requires an "if" and a "when", because its "when" clauses
>must describe conditions that can be reliably reached:

Wrong.  A "when" clause which describes a condition that cannot be
reliably reached is perfectly acceptable in a POSIX.3.1 assertion.
It simply means the assertion must be classified as extended.

--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]

Volume-Number: Volume 25, Number 75

From [e-mail]  Thu Oct 10 21:05:08 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07044; Thu, 10 Oct 91 21:05:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22194; Thu, 10 Oct 91 21:04:56 -0400
Newsgroups: comp.std.unix
From: Bob Lenk <[e-mail]>
Subject: Re: Error detection
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Fri, 11 Oct 1991 00:44:03 GMT
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Geoff Clare) writes:

> >Exactly.  That is why POSIX.1 does not require two "if"s.  POSIX.3.1
> >probably requires an "if" and a "when", because its "when" clauses
> >must describe conditions that can be reliably reached:
>
> Wrong.  A "when" clause which describes a condition that cannot be
> reliably reached is perfectly acceptable in a POSIX.3.1 assertion.
> It simply means the assertion must be classified as extended.

I'm not sure how much of my statement Geoff means is wrong.  I stand
corrected that the "when" clause does not have to be reliably reached.
A correct statement would be that a "when" clause that is not restricted
by an "if" clause must be reachable (whether or not reliably or portably)
on all conforming implementations.

If Geoff meant that POSIX.3(.1) does not require both "if" and "when", I
am less certain.  I have given roughly the same argument to several of
the POSIX.3 working group members in the past.  The logical conclusion
is that conditional features can be completely handled by extended
assertions, and there is no need for the distinctions between type B, C,
and D assertions.  The working group clearly wanted a distinction.  I
find that the definition of "conditional feature" in POSIX.3 does little
to really define what that distinction is (it goes into great length to
explain that it is not exactly the same as "optional" in POSIX.1, but
falls short of defining what it is).

One school of thought is that a conditional feature is anything that
occurs on some implementations but not others.  With that definition,
the "feature" under discussion (getc() returning EOF due to an
unreadable file descriptor) would be conditional, and this assertion
would require both "if" and "when" clauses.

If conditional features are indeed closer to POSIX.1 options, a simple
extended assertion with one "when" would suffice.  However, test suite
writers must then understand that it is quite acceptable that a
"when" clause never be true on some conforming implementations (not
only that there may not be a reliable way to reach it, but that it
may be truly unreachable).  The feature under discussion falls into
that category.

In any case, my original point was that, while POSIX.3 has very specific
rules that may require multiple "if"s or "if" and "when", POSIX.1
is written in English.  Thus assertion writers cannot simply count
the number of "if"s in POSIX.1 to determine how POSIX.3.1 assertions
need to be written.

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


Volume-Number: Volume 25, Number 76

From [e-mail]  Mon Oct 14 05:58:51 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05789; Mon, 14 Oct 91 05:58:51 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01959; Mon, 14 Oct 91 05:58:44 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, P1201.1: Windowing Toolkit API
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Sun, 13 Oct 1991 23:05:15 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
P1201.1: Windowing Toolkit API


Luisa Johnson, Harris Space Systems reports on the July 8- 12, 1991
meeting in Santa Clara, CA:

The P1201.1 Working Group's attendance was significantly lower than
that of previous P1201.1 quarterly working group sessions.  Most
participants expected much controversy due to the recent selection of
the base and reference documents at the Boulder meeting in May.
Fortunately, the participants that did show up for the week long
meetings were more eager to start drafting the standards document than
arguing over document selection.  After all, these documents are only
informational sources to be used in the drafting of the standard and
the layered API standards document itself will most likely not
resemble either of them.

The working group was fairly well represented by both layered API
developers and current or future users.  With the exception of the
first morning session, no representatives from any major toolkit or
hardware vendor actively participated in the P1201.1 sessions the rest
of the week.

The working group spent the first morning discussing the usual
administrative items and identifying a strategy to be used for the
rest of week in order to generate the first standard draft document.
The strategy consisted of:

   - reviewing the strawman document outline,

   - identifying areas to be deferred or to be omitted from
     the standard,

   - identifying and describing a basic list of objects
     including their attributes.

As a result of the document outline review process, a few minor
modifications and additions were made to the General section, the
Terminology and General Requirements section, and appendices were
identified by the group.  Topics covered by the group included:

   - internationalization concerns,

   - geometry management and anchoring,

   - color,

   - cursors,

Rationale will be added regarding the basic requirements list,
language bindings, and the process that was used to select the base
and reference documents.

The next area tackled by the group was that of identifying areas to
defer for future meeting discussions or topics to omit from the
standard.  If the area had been or is currently being addressed by
other working or standards groups, then it was considered out of our
standard's scope.  Areas such as drawing, resource formats, and
resource languages, were identified as possible areas to expand on
once the initial first draft is completed.

WNDX Corporation made a presentation to the working group.  There
product allows developers to specify a look and feel that may be
different from the underlying GUI's ``look-and- feel .'' It is
implemented to the native library and emulates the style guide, so a
developer could select the MacIntosh ``look-and-feel '' on a UNIX
Windows environment.  WNDX Corporation representatives informed the
group of their desire to participate in this standard's effort and the
working group agreed that the standards effort could only benefit with
the inclusion of new approaches and their lessons learned.

>From the second day through the end of the week, P1201.1 worked
diligently on the identification of objects and attributes.  This
became an iterative process by which the first pass was a simple
candidate list of objects which became further defined each day.
Attributes were assigned and refined throughout the week.  No effort
was devoted to the specific syntax and semantics to be utilized.
Instead, for each object, pointers to both the Base and Reference
documents were annotated for further details.  By the end of the week,
a robust set of objects and attributes had been identified and the
working group members felt a sense of accomplishment which none had
anticipated.  Working group members felt that this had been one of the
most fruitful meetings in their turbulent history.  The next mailing
will include the approved first draft.

With the lack of participation by any major GUI vendor, one can only
wonder if the accomplishments achieved during this week could have
been obtained had they not been so busy fighting the GUI PAR wars.

Volume-Number: Volume 25, Number 77

From [e-mail]  Tue Oct 15 23:28:40 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06507; Tue, 15 Oct 91 23:28:40 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13827; Tue, 15 Oct 91 23:28:29 -0400
Newsgroups: comp.std.unix
From: Clive Feather <[e-mail]>
Subject: Shell character classes.
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 15 Oct 1991 14:17:18 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Clive Feather)

Can someone please send me a description of the character classes (i.e. the
"[...]" form of wildcard) in the Posix shell syntax, including any
internationalization facilities. Note that I explicitly want the shell
wildcards, and not normal regular expressions.

Thanks in advance.

--
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
[e-mail]          | 62-74 Burleigh St.  | it will get its revenge.
Phone: [phone] | Cambridge   CB1 1OJ |   - Henry Spencer
(USA: 1 800 XDESK 57)  | United Kingdom      |


Volume-Number: Volume 25, Number 78

From [e-mail]  Wed Oct 16 14:32:24 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27016; Wed, 16 Oct 91 14:32:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28679; Wed, 16 Oct 91 14:32:11 -0400
Newsgroups: comp.std.unix
From: "John S. Morris" <[e-mail]>
Subject: Re: Standards Update, P1201.1: Windowing Toolkit API
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Open Software Foundation
References: <[e-mail]>
Date: Wed, 16 Oct 1991 17:01:53 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Morris)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>Submitted-by: [e-mail] (Peter Collinson)
>
>
>With the lack of participation by any major GUI vendor, one can only
>wonder if the accomplishments achieved during this week could have
>been obtained had they not been so busy fighting the GUI PAR wars.
>
There is an up side to non-participation and a down side. The up side
has been pointed out here - yes, some forms of work can progress much
more quickly within a small group, however a down side of non-participation,
particularly from the several experts in X Window System toolkits who have
participated in the past, means there is a body of knowledge and experience
in GUI architectures which is no longer available. That may mean that some
of the work to come will not happen as quickly as some would like to think.

-John
============================================================================
John S. Morris                  ___   ___   ___        Voice: [phone]
Open Software Foundation       /  /  /__   /__           Fax: [phone]
11 Cambridge Center           /__/  ___/  /         Internet: [e-mail]
Cambridge, MA  02142                                    uucp: uunet!osf!jsm


Volume-Number: Volume 25, Number 79

From [e-mail]  Thu Oct 17 00:14:05 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22276; Thu, 17 Oct 91 00:14:05 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20602; Thu, 17 Oct 91 00:13:52 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, POSIX.7: System Administration
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Wed, 16 Oct 1991 14:26:41 GMT
Reply-To: [e-mail]
To: [e-mail]

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.7: System Administration


Martin Kirk <[e-mail]> reports on the July 8-12, 1991
meeting in Santa Clara, CA:

The July meeting of the POSIX.7 (System Administration) working group
continued the new direction established over the previous two meetings.

Small groups continued work on Printer Management, Software
Management, and further refinement of the ``Big Sticky Issues'', i.e.
the global context of these activities.

The most important results from the ``Sticky Issues'' small group were
recommendations for the style and content of POSIX.7 standards.  Their
final recommendations will bring the group into full alignment with
the rest of POSIX.  The overall structure for each functional area
standard will have sections for:

   - POSIX.1 style programmatic interfaces based on existing practice

   - POSIX.2 style command line interfaces based on existing practice

   - Managed object definitions to provide a basis for the distributed
     system administration functionality [Ed. -- It is appropriate to
     mention that these have no relationship to the communications
     object types to be managed with the object management API being
     defined by P1224 and POSIX.17.]

This approach represents a compromise between ``traditional'' systems
administration and the object-oriented approach.  Where there are
existing interfaces available they will be used.  They will be
supplemented by managed object definitions needed to provide uniform
interoperability between different implementations.

Adopting this approach, along with the earlier decision to build
separate functional area standards instead of a monolithic tome,
should enable the group to progress more swiftly.

The Print Management group has been pursuing an approach based on the
MIT Palladium distributed printing system.  They received a strong
contribution from the UNIX Systems Lab (USL) championing the System V
lp print system.  This was a timely interjection, allowing us the
opportunity to address the issues that would have undoubtedly arisen
during the balloting process.  By identifying both the common subset
and the differences it should be possible to provide the appropriate
rationale for the contents of the eventual standard.

The Software Management group continued to make good progress.  They
are working with contributions from several sources, including AT&T,
DEC, HP, Siemens-Nixdorf, and SCO.  (My apologies to anyone I left
out).  As one would expect, all these differing systems are remarkably
similar in terms of the functionality they present to the user, and
thus the group found it relatively painless to identify the large
common subset between them.

The group's other activity was to identify a third functional area in
which to commence work.  The chosen candidate was User Management as
it was felt that many other system resources were managed in terms of
their relationship to users.

By the time the next POSIX meeting takes place in October, the OSF
Distributed Management Environment selection will have been
announced.  It will be very interesting to see what effect this has on
the system administration standards process.


Volume-Number: Volume 25, Number 80

From [e-mail]  Thu Oct 17 15:34:46 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05118; Thu, 17 Oct 91 15:34:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14649; Thu, 17 Oct 91 15:34:32 -0400
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Thu, 17 Oct 1991 11:38:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>The most important results from the ``Sticky Issues'' small group were
>recommendations for the style and content of POSIX.7 standards.  Their
>final recommendations will bring the group into full alignment with
>the rest of POSIX.  The overall structure for each functional area
>standard will have sections for:
>
>   - POSIX.1 style programmatic interfaces based on existing practice
>
>   - POSIX.2 style command line interfaces based on existing practice

  So far, so good.  I hope that they use common sense in selecting
command line interfaces like lp/lpr/lpq/lprm/lpstat rather than more
obscure, less widely used ones.

>  The Print Management group has been pursuing an approach based on the
>MIT Palladium distributed printing system.  They received a strong
>contribution from the UNIX Systems Lab (USL) championing the System V
>lp print system.  This was a timely interjection, allowing us the
>opportunity to address the issues that would have undoubtedly arisen
>during the balloting process.  By identifying both the common subset
>and the differences it should be possible to provide the appropriate
>rationale for the contents of the eventual standard.

  Note Clearly that MIT Palladium is NOT "existing practice" outside
of MIT and as such is best left out of POSIX for now.  The POSIX
groups should concentrate on standardising EXISTING PRACTICE in a
clean manner.  Palladium might or might not be wonderful, but there is
insufficient experience in using it outside the MIT and especially MIT
Athena environment to justify including it in POSIX.

  Existing practice is what is in UNIX System V and in 4BSD systems.
Palladium hasn't been in either and there isn't enough experience
with it to make it a basis for standards work.


>The group's other activity was to identify a third functional area in
>which to commence work.  The chosen candidate was User Management as
>it was felt that many other system resources were managed in terms of
>their relationship to users.

  This isn't even close to being clear.  What is meant by "User Management"
and could we please have some examples ??

  Why do I get the feeling that the POSIX effort has gotten completely
out of hand and is now inventing new areas to "standardise" that
aren't appropriately standardised yet because they aren't well
understood and we haven't the collective experience with the
technology yet...

Randall Atkinson
[e-mail]  (note new address :-)



Volume-Number: Volume 25, Number 81

From [e-mail]  Thu Oct 17 16:46:15 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10657; Thu, 17 Oct 91 16:46:15 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06771; Thu, 17 Oct 91 16:46:05 -0400
Newsgroups: comp.std.unix
From: "John S. Morris" <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Open Software Foundation
References: <[e-mail]> <[e-mail]>
Date: Thu, 17 Oct 1991 20:05:02 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John S. Morris)

In article <[e-mail]> [e-mail] writes:
>
>  Note Clearly that MIT Palladium is NOT "existing practice" outside
>of MIT and as such is best left out of POSIX for now.  The POSIX
>groups should concentrate on standardising EXISTING PRACTICE in a
>clean manner. [....deleted]
>  Why do I get the feeling that the POSIX effort has gotten completely
>out of hand and is now inventing new areas to "standardise" that
>aren't appropriately standardised yet because they aren't well
>understood and we haven't the collective experience with the
>technology yet...

Exactly. Couldn't be said better. Why is it that we aren't applying
the same reasoning to 1201.1? Why are we inventing technology in
standards committees via API's? Don't we have enough examples of what
that leads to?  Sigh.....

-John
============================================================================
John S. Morris                  ___   ___   ___        Voice: [phone]
Open Software Foundation       /  /  /__   /__           Fax: [phone]
11 Cambridge Center           /__/  ___/  /         Internet: [e-mail]
Cambridge, MA  02142                                    uucp: uunet!osf!jsm


Volume-Number: Volume 25, Number 82

From [e-mail]  Thu Oct 17 17:56:59 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26919; Thu, 17 Oct 91 17:56:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28667; Thu, 17 Oct 91 17:56:50 -0400
Newsgroups: comp.std.unix
From: "Matthew J. Wicks" <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Fermi National Accelerator Laboratory, Batavia IL
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Thu, 17 Oct 1991 21:32:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Matthew J. Wicks)

In article <[e-mail]>, [e-mail] writes:
> In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>   This isn't even close to being clear.  What is meant by "User Management"
> and could we please have some examples ??

I'm not sure if I know all the things that is meant by user management,
but is contains things like:

    Account addition and deletion
    Group addition and deletion
    Adding and deleting members from groups

I believe it will also include more complex things as well.

>   Why do I get the feeling that the POSIX effort has gotten completely
> out of hand and is now inventing new areas to "standardise" that
> aren't appropriately standardised yet because they aren't well
> understood and we haven't the collective experience with the
> technology yet...

I don't believe POSIX.7 is currently addressing areas to standardise that
aren't well understood. Printer management, software management, and user
management is partially define above are things that people have been doing
and  have "solved" for a long time. I believe your difficulty may be with
how a certain area is standardised. It seems as if you believe that Palladium
doesn't belong in the standard. However, that is something totally different
from believing that printer management shouldn't be standardised.

--
Matt Wicks
Fermi National Accelerator Laboratory
[e-mail]
708-840-8083


Volume-Number: Volume 25, Number 83

From [e-mail]  Thu Oct 17 20:00:28 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04746; Thu, 17 Oct 91 20:00:28 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07795; Thu, 17 Oct 91 20:00:17 -0400
Newsgroups: comp.std.unix
From: Duke Robillard <[e-mail]>
Subject: POSIX.7, Printing+Palladium, User Management
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Bellcore, Piscataway, NJ
References: <[e-mail]> <[e-mail]>
Date: Thu, 17 Oct 1991 21:55:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

[As background, I'm in the POSIX.7 group.  I'm the technical editor,
and I'm working in the Printing Small Group]

In an article in comp.std.unix, [e-mail] writes:

>...selecting
>command line interfaces like lp/lpr/lpq/lprm/lpstat rather than more
>obscure, less widely used ones.

>>  The Print Management group has been pursuing an approach based on the
>>MIT Palladium distributed printing system.
>  Note Clearly that MIT Palladium is NOT "existing practice" outside
>of MIT and as such is best left out of POSIX for now.

I understand your point, but that's not the way the group is moving.
Thanks to the influence of Jeff Peacock, formally of USL, the latest
version of the draft is much less Palladium-esque than before, but
Palladium is still one of the base documents.  The command set will
most likely not be lp/lpstat/etc.  And the programmer API for the
print system is still likely to be based on Palladium, since there
isn't one for SVR4 lp.

If this bugs people, I would suggest that they come to Parsippany
next week to yell at us in person.  If it turns out that most people
think we're wrong, we'll change.

(As a side note, Palladium was recently selected for OSF's DME,
so it's about to become much more widespread)

>>which to commence work.  The chosen candidate was User Management as
>>it was felt that many other system resources were managed in terms of
>>their relationship to users.
>  This isn't even close to being clear.  What is meant by "User
>Management" and could we please have some examples ??

A problem with standards groups is that they get caught up in their
own jargon.  (For example, I find it almost impossible to understand
people from the OSI groups)  "User Management" is dealing with the
stuff related to user accounts.  This includes the stuff traditionally
in /etc/password, quotas, /etc/group, stuff like that.

>  Why do I get the feeling that the POSIX effort has gotten completely
>out of hand and is now inventing new areas to "standardise" that
>aren't appropriately standardised yet because they aren't well
>understood and we haven't the collective experience with the
>technology yet...

This is a real danger.  We don't think that it is happening, but
it is a concern.

I suspect there are people out there who agree with the criticisms
leveled in this posting.  I would say that the best way to address
these issues is to come to a meeting and complain.  We WILL listen.
You could have a major impact--the USL person who championed lp
last time did.

The next meeting is next week, Oct 21-25 in Parsippany, NJ.  The
one after that is January 13-17, in Irvine, CA.

Bob Robillard
Duke Robillard                              DoD #0130
Internet:   [e-mail]
USENET:     {backbone}!bcr!pyuxv!duke


Volume-Number: Volume 25, Number 84

From [e-mail]  Tue Oct 22 02:58:23 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27352; Tue, 22 Oct 91 02:58:23 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00283; Tue, 22 Oct 91 02:09:51 -0400
Newsgroups: comp.std.unix
From: "Scott E. Preece" <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Sun, 20 Oct 1991 05:31:26 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scott E. Preece)

| >  Why do I get the feeling that the POSIX effort has gotten completely
| >out of hand and is now inventing new areas to "standardise" that
| >aren't appropriately standardised yet because they aren't well
| >understood and we haven't the collective experience with the
| >technology yet...
|
| Exactly. Couldn't be said better. Why is it that we aren't applying
| the same reasoning to 1201.1? Why are we inventing technology in
| standards committees via API's? Don't we have enough examples of what
| that leads to?  Sigh.....
|
| -John
---
1201.1 is working on distilling a standard from the experience of a
group of technology providers whose experience covers a wide range of
hardware and operating systems and who have strong ideas about what
works and what doesn't work.  My impression is that that was the way an
IEEE working group was supposed to work.  The group is not "inventing
technology through APIs", it is on the contrary developing an API that
expresses several existing technologies.  The people representing those
technologies in 1201.1 are working together to make sure the resulting
API suits the needs of their technologies.  The result should be
eminently implementable and I would expect that some of the work group
members will have implementations by the time the group is ready to ballot.

I like that model for developing a standard far better than one which
would allow a single technology vendor to say "We'd like to have our
technology be published as an IEEE standard, please; the standard has to
be exactly what our product is and the balloting rules have to be that
anything that would change it is out of scope."  If POSIX had taken that
model when it began, we would no doubt have "IEEE Standard BSD UNIX" and
"IEEE Standard System V UNIX" and "IEEE Standard HP-UX" and "IEEE
Standard Ultrix" and the net gain in application portability would have
been approximately zero.

If one is looking for danger, one might look at the move this Summer by
a group of large companies (including, I am sorry to say, my own) to
push the IEEE to bless as standards products which hadn't even been
described yet, like the OSF DME offering.  The people pushing that
movement clearly believe that having a single standard is much more
important than whether the standard is a good one.

scott

--
scott preece
(In this forum, as at IEEE TCOS meetings, I hang my Motorola hat at the
door; I speak *only* for myself. That's the way the book says it's
supposed to work.)

motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]


Volume-Number: Volume 25, Number 85

From [e-mail]  Thu Oct 24 06:48:53 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28891; Thu, 24 Oct 91 06:48:53 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23459; Thu, 24 Oct 91 06:48:26 -0400
Newsgroups: comp.std.unix
From: Kee Hinckley <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: asi
References: <[e-mail]>
Date: Wed, 23 Oct 1991 17:45:44 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Kee Hinckley)

In article <[e-mail]> [e-mail] (Scott E. Preece) writes:
>IEEE working group was supposed to work.  The group is not "inventing
>technology through APIs", it is on the contrary developing an API that
>expresses several existing technologies.  The people representing those

I have to disagree.  There are two technologies involved here.  GUI toolkits,
and virtual toolkits (layered on anything, GUI or not).  P1201 is not
reinventing the first, I'll grant that.  But it is reinventing the second.
Virtual toolkits are an unproven technology (sample implementations have
only existed for a few years and have not been used in any major commercial
applications that I'm aware of).  It is also not at all clear that software
developers would want or could use such toolkits.  A quick survey of Mac
applications shows that almost all of them extend the toolkit in one way
or another, but such extensions are not portable and often not even possible
in a virtual toolkit.  Software developers have complained greatly about
the speed and memory intensiveness of existing X toolkits, yet a virtual
toolkit will *increase* the size and weight of applications.

Unfortunately most software development houses can't afford to send someone
to P1201 meetings.  I can barely afford the time to read the mailings.

P1201 is inventing new technology, and it is doing so soley because it
was unable to overcome the political problems that would have entailed
from selecting or extending existing technology.  I firmly believe that
the reason that P1201 is now off and doing work without political
interference is that the task they have set for themselves is so
ridiculously impossible (at least in any substantially useful implementation)
that no one is worried about it ever becoming a competitive standard.


--
Alfalfa Software, Inc.          |       Poste:  The EMail for Unix
[e-mail]              |       Send Anything... Anywhere
617/497-2922                    |       [e-mail]

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 25, Number 86

From [e-mail]  Thu Oct 24 06:49:15 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28926; Thu, 24 Oct 91 06:49:15 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23504; Thu, 24 Oct 91 06:48:46 -0400
Newsgroups: comp.std.unix
From: "John S. Morris" <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Open Software Foundation
References: <[e-mail]>
Date: Wed, 23 Oct 1991 19:40:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John S. Morris)

In article <[e-mail]> [e-mail] (Scott E. Preece) writes:
>1201.1 is working on distilling a standard from the experience of a
>group of technology providers whose experience covers a wide range of
>hardware and operating systems and who have strong ideas about what
>works and what doesn't work.  My impression is that that was the way an

I'm glad to see 1201.1 has changed since the last time I sat in.
And it appears to be on a much more pragmatic path according to your
description.

>I like that model for developing a standard far better than one which
>would allow a single technology vendor to say "We'd like to have our
>technology be published as an IEEE standard, please; the standard has to
>be exactly what our product is and the balloting rules have to be that
>anything that would change it is out of scope."  If POSIX had taken that
>model when it began, we would no doubt have "IEEE Standard BSD UNIX" and
>"IEEE Standard System V UNIX" and "IEEE Standard HP-UX" and "IEEE
>Standard Ultrix" and the net gain in application portability would have
>been approximately zero.

Well, I have to disagree. I don't find anything in the IEEE or the
Computer Society rules that says this is what the IEEE is about.
And when one looks at the realm of IEEE standards, I think 1003.1
stands out as the exception rather than the rule. For example, look
at all the hardware standards (many more than POSIX after all) and
see how many fit your description. On the other how many applications
have been written to 1003.1 versus the single product DOS? I believe
there are many valid reasons for standardizing on an existing specification
rather than "harmonizing" a series of similar specs.

Your quote of the intent of my PAR is an interesting one - given that I
specifically negated that assertion in the TCOS/SS-SEC. People sometimes
read more into things than are really there. If you check the wording
of the PAR it is consistent with the intent of the proposal and not at
all in violation of IEEE rules. And once the standard is approved - it
is a completely moot point, since then the IEEE would own all rights to
the specification and it could evolve in whatever direction the IEEE
would like.

Anyway, if in your model, standards could be developed as quickly as
end users want them - I'd have some different opinions.

>If one is looking for danger, one might look at the move this Summer by
>a group of large companies (including, I am sorry to say, my own) to
>push the IEEE to bless as standards products which hadn't even been
>described yet, like the OSF DME offering.  The people pushing that
>movement clearly believe that having a single standard is much more
>important than whether the standard is a good one.

Sorry, I don't know anything about this. OSF has never had such a policy
in any case. The Motif proposal was made after three years of experience
and at the request of more than fifty end users, ISV's and system
vendors. If you saw my proposal, you would notice many significant
organizations supporting it. Such a move is no doubt related to the
great demand for standards in this area.

>(In this forum, as at IEEE TCOS meetings, I hang my Motorola hat at the
>door; I speak *only* for myself. That's the way the book says it's
>supposed to work.)

Actually the book says more than that. In TCOS I represent my organization
as an Institutional Representative not myself. (It also happens that
personally I agree with most of my organziations' perspectives 8-)).

-John
============================================================================
John S. Morris                  ___   ___   ___        Voice: [phone]
Open Software Foundation       /  /  /__   /__           Fax: [phone]
11 Cambridge Center           /__/  ___/  /         Internet: [e-mail]
Cambridge, MA  02142                                    uucp: uunet!osf!jsm


Volume-Number: Volume 25, Number 87

From [e-mail]  Tue Oct 29 03:44:14 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19079; Tue, 29 Oct 91 03:44:14 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10527; Tue, 29 Oct 91 03:43:47 -0500
Newsgroups: comp.std.unix
From: "Scott E. Preece" <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 28 Oct 1991 16:19:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scott E. Preece)

Kee Hinckley writes:

| Virtual toolkits are an unproven technology (sample implementations have
| only existed for a few years and have not been used in any major commercial
| applications that I'm aware of).  It is also not at all clear that software
| developers would want or could use such toolkits.  A quick survey of Mac
| applications shows that almost all of them extend the toolkit in one way
| or another, but such extensions are not portable and often not even possible
| in a virtual toolkit.  Software developers have complained greatly about
| the speed and memory intensiveness of existing X toolkits, yet a virtual
| toolkit will *increase* the size and weight of applications.
---
Unless all the vendors who spoke to the committee are lying
outrageously, there are in fact *a lot* of major applications fielded
using one virtual toolkit or another.  Most of the instances presented
to the group were in-house projects rather than software for sale,
though some of the major ISVs have their own virtual toolkits which do
underly released commercial products.  Some ISVs will clearly not want
to use a layered toolkit, just as some ISVs build wholly separate
products for different operating systems; if you have the time and
resources, are willing to deal with out-of-synch releases on different
bases, and want to make sure you get the absolute last bit of
performance and polish on each platform, that's the only way to go.  On
the other hand, delivering a product that is slightly slower and
slightly larger and uses slightly less of the maximum envelope of
functionality on each toolkit, *but* uses exactly the same source base
on each platform allows the developer to concentrate on application
functionality, rather than interface functionality, and helps insure
that releases on all platforms are in synch and that fixing a bug found
on one platform fixes the same bug for all platforms.  These are not
small advantages.

As to the second point (that most applications extend the toolkit), one
could argue that such extensions are not a good thing -- that they
either indicate shortcomings in the toolkit or failure of the developers
to live within the rules, at risk of confusing their users.
In any case, the vendors working in P1201.1 all provide mechanisms for
getting to the underlying toolkit, when developers are willing to
sacrifice portability for some other factor.

scott

--
scott preece
motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]


Volume-Number: Volume 25, Number 88

From [e-mail]  Thu Oct 31 07:12:17 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27798; Thu, 31 Oct 91 07:12:17 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06816; Thu, 31 Oct 91 07:09:13 -0500
Xref: kithrup comp.std.unix:405 comp.std.internat:694
Newsgroups: comp.std.unix,comp.std.internat
From: Andrew Hume <[e-mail]>
Subject: Storing identifiers
Message-Id: <[e-mail]>
Followup-To: comp.std.internat
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: Thu, 31 Oct 1991 02:08:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Hume)

    I am the technical editor for a working paper
covering file system formats for write once and rewritable disks
within X3. This paper is also about to be taken as teh base
paper for ECMA and eventually ISO conideration.

    the question i have has to do with various identifier fields.
These are fixed lengths, mostly 128 bytes but some are 32 bytes.
We support all sorts of character sets, including 2022 and 10646
(when that gets fixed), but we believe that in practice, most
use will be with one-byte-per-char charsets. Accordingly, we
would like the fields to include at least one (00) byte (they
will be (00) filled on the right anyway) so they are conveniently
handled from C.

    the actual question is whether one null is enough or should
we have 4 (00) bytes? My feeling is that multi-byte char folks
tend not to use null terminators but i don't know. These fields
do not have lengths associated with them.

    andrew hume
    [e-mail]

[ Note the followup-To, comp.std.unix readers -- mod ]

Volume-Number: Volume 25, Number 89

From [e-mail]  Fri Nov  1 15:41:06 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02216; Fri, 1 Nov 91 15:41:06 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20284; Fri, 1 Nov 91 15:40:44 -0500
Newsgroups: comp.std.unix
From: Kee Hinckley <[e-mail]>
Subject: Re: POSIX.7 Update
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: asi
References: <[e-mail]>
Date: Thu, 31 Oct 1991 21:33:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Kee Hinckley)

In article <[e-mail]> [e-mail] (Scott E. Preece) writes:
>| Virtual toolkits are an unproven technology (sample implementations have
>| only existed for a few years and have not been used in any major commercial
>| applications that I'm aware of).  It is also not at all clear that software
>| developers would want or could use such toolkits.  A quick survey of Mac
>| applications shows that almost all of them extend the toolkit in one way
>| or another, but such extensions are not portable and often not even possible
>| in a virtual toolkit.  Software developers have complained greatly about
>| the speed and memory intensiveness of existing X toolkits, yet a virtual
>| toolkit will *increase* the size and weight of applications.
>---
>Unless all the vendors who spoke to the committee are lying
>outrageously, there are in fact *a lot* of major applications fielded
>using one virtual toolkit or another.  Most of the instances presented

Examples?

>to the group were in-house projects rather than software for sale,
>though some of the major ISVs have their own virtual toolkits which do
>underly released commercial products.  Some ISVs will clearly not want

The task of writing a virtual toolkit for an ISV is very different than
that of writing one for the entire industry.  Extensibility is no longer
as important, and functionality can be limited to those features that
that particular ISV needs.  There are vendors who have multiple-GUI
toolkits that they use for major commercial products (Neuron Data
comes to mind), but that's a very different beast than a toolkit which
overlays an number of existing GUI toolkit.

>performance and polish on each platform, that's the only way to go.  On
>the other hand, delivering a product that is slightly slower and
>slightly larger and uses slightly less of the maximum envelope of
>functionality on each toolkit, *but* uses exactly the same source base

I picked a random assortment of Mac applications one day (around 20
or so) and found *none* which didn't extend the toolkit in some way.
If you believe that a virtual toolkit can be built which is only somewhat
larger (and the Unix toolkits are mainly too large already) and only
slightly slower (I finally saw a Unix machine that ran it's GUI as fast
as a Mac - but it took an HP700 to pull it off), and still have room
for extensibility (both in terms of future enhancements and vendor
needs), internatinalization, resolution independent geometry management...
and all of the other things which the P1201 documents claim to have
as goals - then by all means, do it.  Maybe I'm just being pessimistic,
but I just don't believe it's possible.

>that releases on all platforms are in synch and that fixing a bug found
>on one platform fixes the same bug for all platforms.  These are not

That raises an interesting issue.  None of the current Unix GUI toolkits
are renouned for their bug-free features.  Finding those bugs is
currently a major task.  Adding another toolkit on top of them is
going to make that task even harder.

>As to the second point (that most applications extend the toolkit), one
>could argue that such extensions are not a good thing -- that they
>either indicate shortcomings in the toolkit or failure of the developers
>to live within the rules, at risk of confusing their users.

No general toolkit can, or should be expected to, anticipate the needs
of all applications.  In a dynamic environment applications are
constantly pushing the GUI envelope, and the toolkits play catch up
by looking at those apps which seem to have done a good job and adding
those features that seem worthwhile.  It's a constant evolutionary
pattern, with the marketplace making the choices.  Any attempt to
cut off such extensions or worse yet, place them in the sole control
of the toolkit vender, is a sure recipe for failure.

>In any case, the vendors working in P1201.1 all provide mechanisms for
>getting to the underlying toolkit, when developers are willing to
>sacrifice portability for some other factor.

I understand that this is a goal of P1201.1, and in fact I consider
it, and the other goals expressed, all quite laudable.  But I'm not
a politician, I'm a techie, and I've yet to see a technical explanation
for how those goals are going to come to pass.

A slight side note.  I had a conversation off-line (so to speak) with
someone about this subject.  During that discussion I did come to the
realization that one good thing could come from P1201.1.  If the
API were well-designed, it would be possible to write a toolkit using
the API that was *not* virtual, and thus would not have a number of
the design problems that a virtual toolkit must suffer from.  The
drawback to this is that a good toolkit API is going to have some
different design goals (and less limitations) than a VAPI, so it's
unlikely that such a toolkit would overcome much more than the speed
and memory problems.  However, if P1201.1 is to become generally used
I suspect that it will only happen if such "native" toolkits are
written.

                            -kee
--
Alfalfa Software, Inc.          |       Poste:  The EMail for Unix
[e-mail]              |       Send Anything... Anywhere
617/497-2922                    |       [e-mail]

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 25, Number 90

From [e-mail]  Mon Nov  4 17:48:42 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25914; Mon, 4 Nov 91 17:48:42 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19997; Mon, 4 Nov 91 17:48:29 -0500
Newsgroups: comp.std.unix
From: Bob Bagwill <[e-mail]>
Subject: Current P1201.1 PAR [was Re: POSIX.7 Update]
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: uniform layerable
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Computer Systems Lab
References: <[e-mail]> <[e-mail]>
Date: Mon, 4 Nov 1991 17:00:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

FYI, the current P1201.1 PAR refers to a Uniform (rather than Virtual)
API, and the API must be layerable (rather than layered) on top of
multiple toolkits (Macintosh, MS Window, OpenLook, Motif, etc).
That means an API vendor can do whatever they like to make the
API efficient for a particular platform, including circumventing the
native toolkit, if necessary or possible.

--
Bob Bagwill
NIST P1201.1 attendee
--
Bob Bagwill    NIST/Computer Systems Lab/Software Engineering Group


Volume-Number: Volume 25, Number 91

From [e-mail]  Wed Nov  6 01:53:13 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18559; Wed, 6 Nov 91 01:53:13 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05214; Wed, 6 Nov 91 01:53:10 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 4 Nov 1991 00:32:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]


I would like to know whether or not AT&T UNIX System V Release 4 complies with
the POSIX 1003.2 and 1003.2a draft standards for shell and utilities?  What
about X/Open XPG3 and XPG4?

Please reply by mail to Bill Norcott at:

     [e-mail]

Regards,
Bill Norcott


Volume-Number: Volume 25, Number 92

From [e-mail]  Wed Nov 13 16:31:47 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09256; Wed, 13 Nov 91 16:31:47 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27022; Wed, 13 Nov 91 16:31:38 -0500
Newsgroups: comp.std.unix
From: Dave Cline <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Thu, 7 Nov 1991 19:06:55 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Cline)

In [e-mail] writes:
> I would like to know whether or not AT&T UNIX System V Release 4 complies with
> the POSIX 1003.2 and 1003.2a draft standards for shell and utilities?  What
> about X/Open XPG3 and XPG4?

When you say SVR4, you've got to qualify it with an architecture.  It's
not monolithic.

To the best of my knowledge, 1003.2 isn't final yet.

I believe current SVR4 is not compatible with the current P1003.2 draft.

Dave Cline                            uucp: ...uunet!88opensi!dave
88open Consortium, Ltd.                     [e-mail]
100 Homeland Court, Suite 800
San Jose, CA 95112

Volume-Number: Volume 25, Number 93

From [e-mail]  Thu Nov 14 04:29:12 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10256; Thu, 14 Nov 91 04:29:12 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14341; Thu, 14 Nov 91 04:29:04 -0500
Newsgroups: comp.std.unix
From: Perry Lewis <[e-mail]>
Subject: FIPS 151-1 conflict
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Kanatek
Date: Wed, 13 Nov 1991 22:13:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Perry Lewis)

Perhaps someone out there can clear up a problem for me. A customer of ours
who has a network of Sun systems and Interactive SVR3.2.2 systems reported
that these 2 operating systems have implemented the FIPS 151-1 multiple
groups specification differently. Both systems load a table of group id's
the user belongs to into kernel space upon login from the /etc/group file.
However, on the Sun, the user can access any file which is owned by one of
his groups simultaneously. On the Interactive system, the user must execute
a newgrp to access a file owned by one of his groups. Therefore, Sun users
can simultaneously access files owned by 8 different groups while Interactive
users can only access one group at a time.

    A call to Interactive support informed me that their implementation
was correct. They weren't concerned that Sun had done it differently. Which
one is correct?

--
____________________________________________________________________________
Perry W. Lewis                  |   [e-mail]
Kanatek Technologies            |   Voice: [phone]
Kanata, Ontario, Canada         |   FAX:   [phone]


Volume-Number: Volume 25, Number 94

From [e-mail]  Thu Nov 14 19:12:39 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01483; Thu, 14 Nov 91 19:12:39 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27304; Thu, 14 Nov 91 19:12:25 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: FIPS 151-1 conflict
Message-Id: <[e-mail]>
Summary: It's complicated.
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Stanford Univ. Earth Sciences
References: <[e-mail]>
Date: Thu, 14 Nov 1991 23:40:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail]
(Perry Lewis) writes:
>
>However, on the Sun, the user can access any file which is owned by one of
>his groups simultaneously. On the Interactive system, the user must execute
>a newgrp to access a file owned by one of his groups. Therefore, Sun users
>can simultaneously access files owned by 8 different groups while Interactive
>users can only access one group at a time.

The file group class described in POSIX.1 matches the SunOS
behavior.  However, the 'newgrp' implementation, with or without
a group password, meets the POSIX definition of an additional
file access control mechanism.  This conforms to FIPS 151-1 as
long as it's documented properly in the application to NIST.

>    A call to Interactive support informed me that their implementation
>was correct. They weren't concerned that Sun had done it differently. Which
>one is correct?

They both can conform to the letter of the POSIX.1 FIPS.  I'd
rather use a system that works the way Sun's does.
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]


Volume-Number: Volume 25, Number 95

From [e-mail]  Thu Nov 14 19:12:47 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01491; Thu, 14 Nov 91 19:12:47 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27377; Thu, 14 Nov 91 19:12:36 -0500
Newsgroups: comp.std.unix
From: Monika Haerdtner <[e-mail]>
Subject: OSF's ANDF
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IPVR, Universitaet Stuttgart, Germany
Date: Thu, 14 Nov 1991 15:18:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Monika Haerdtner)

I am interested in the specification of the ANDF (architecture-neutral
software distribution format) standard of the OSF. Does anyone have a
copy of this specification or a pointer how to get one. Is it
available on the net?

Thank you very much,
Monika

Volume-Number: Volume 25, Number 96

From [e-mail]  Fri Nov 15 04:07:00 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21361; Fri, 15 Nov 91 04:07:00 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15733; Fri, 15 Nov 91 04:06:57 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Fri, 15 Nov 1991 07:10:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Dave Cline) writes:
>I believe current SVR4 is not compatible with the current P1003.2 draft.

Another way to phrase that is that draft IEEE Std 1003.2 does not
reflect existing UNIX practice.


Volume-Number: Volume 25, Number 97

From [e-mail]  Fri Nov 15 14:47:30 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03457; Fri, 15 Nov 91 14:47:30 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22808; Fri, 15 Nov 91 14:47:21 -0500
Newsgroups: comp.std.unix
From: Maarten Litmaath <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: Maarten Litmaath <[e-mail]>
X-Submissions: [e-mail]
Organization: Nat. Inst. for Nuclear and High-Energy Physics, Amsterdam
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Fri, 15 Nov 1991 13:17:44 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Maarten Litmaath)

In article <[e-mail]>,
    [e-mail] (Doug Gwyn) writes:
\In article <[e-mail]>
\    [e-mail] (Dave Cline) writes:
\>I believe current SVR4 is not compatible with the current P1003.2 draft.
\
\Another way to phrase that is that draft IEEE Std 1003.2 does not
\reflect existing UNIX practice.

Indeed, it does not reflect any of all existing _flavours_ of UNIX
practice in full, so what?  Would you rather have a minimal standard
that would guarantee no shell script to be portable that does anything
beyond the complexity of "echo hello world"?  Oh, of course, I forgot
that SVR4 happens to be the perfect UNIX system.


Volume-Number: Volume 25, Number 98

From [e-mail]  Fri Nov 15 14:47:52 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03583; Fri, 15 Nov 91 14:47:52 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22956; Fri, 15 Nov 91 14:47:42 -0500
Newsgroups: comp.std.unix
From: David A Willcox <[e-mail]>
Subject: Re: FIPS 151-1 conflict
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Motorola Computer Group, Urbana Design Center
References: <[e-mail]>
Date: Fri, 15 Nov 1991 14:50:28 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

>Submitted-by: [e-mail] (Perry Lewis)

>Perhaps someone out there can clear up a problem for me. A customer of ours
>who has a network of Sun systems and Interactive SVR3.2.2 systems reported
>that these 2 operating systems have implemented the FIPS 151-1 multiple
>groups specification differently. Both systems load a table of group id's
>the user belongs to into kernel space upon login from the /etc/group file.
>However, on the Sun, the user can access any file which is owned by one of
>his groups simultaneously. On the Interactive system, the user must execute
>a newgrp to access a file owned by one of his groups. Therefore, Sun users
>can simultaneously access files owned by 8 different groups while Interactive
>users can only access one group at a time.

>    A call to Interactive support informed me that their implementation
>was correct. They weren't concerned that Sun had done it differently. Which
>one is correct?

Speaking as an individual who worked on the POSIX.1 standard, but NOT
speaking for IEEE or the POSIX working group as a whole and NOT for my
employer...

The Sun implementation is certainly what was intended by POSIX.1, and
I don't see how Interactive can interpret the standard to allow their
implementation.

(Well, a clarification: Interactive's implementation is allowed by
POSIX.1 if they don't support multiple groups.  However, support for
multiple groups implies the Sun behavior, and multiple group support is
required by FIPS 151-1.  Therefore Interactive's implementation is
allowed under POSIX.1, but not FIPS 151-1.)

To quote the 1988 version of POSIX.1:

    file group class.  A process is in the file group class of a file
    if the process is not in the file owner class and if the effective
    group ID or one of the supplimentary group IDs of the process
    matches the group ID associated with the file.  Other members of
    this class may be implementation-defined.

    supplimentary group ID.  A process has up to {NGROUPS_MAX}
    supplimentary group IDs used in determining file access
    permissions, in addition to the effective group ID. ...

Of course, POSIX.1 doesn't provide any mechanism for filling in the
multiple group IDs of the process; that's considered an administrative
matter outside of the scope of the standard.  I suppose that Interactive
could claim that they support multiple groups, but don't provide any
mechanism to fill in the supplimentary group IDs.  I would put this in
the same class as the implementation that had a fork() function that
always failed with EAGAIN;  it might be, technically, compliant, but I
certainly wouldn't buy it.

I hope that somebody will ask IEEE for an offical interpretation on this
subject.

David A. Willcox
Motorola MCG - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534


Volume-Number: Volume 25, Number 99

From [e-mail]  Fri Nov 15 17:03:59 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03496; Fri, 15 Nov 91 17:03:59 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03627; Fri, 15 Nov 91 17:03:50 -0500
Newsgroups: comp.std.unix
From: "Robert L. Henderson" <[e-mail]>
Subject: Question on Posix.12 Protocol Independent Interface
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX, PII, select
Nntp-Posting-Host: rodan.uu.net
Reply-To: "Robert L. Henderson" <[e-mail]>
X-Submissions: [e-mail]
Organization: NASA Ames Research Center
Date: Fri, 15 Nov 1991 19:50:25 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

To anyone who is involved with Posix.12, the Protocol Independent Interface
working group...

If I plan to develop an application using PII and specifically SNI,  can I
associate a communication handle with a file descriptor?

What I need to do is have a server "select" [sni_gather()]  from a network
channel and a fifo (named pipe).  I can do this today using select() with a
pipe's file descriptor
and a socket.

--

Bob Henderson
[e-mail]
NASA Ames Research Center

"My goal in life?  To find the winning lotto ticket on the sidewalk!"

Volume-Number: Volume 25, Number 100

From [e-mail]  Fri Nov 15 17:04:06 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03528; Fri, 15 Nov 91 17:04:06 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03645; Fri, 15 Nov 91 17:03:56 -0500
Newsgroups: comp.std.unix
From: Jason Zions <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Colorado Networks Division, Hewlett-Packard Co.
References: <[e-mail]> <[e-mail]>
Date: Fri, 15 Nov 1991 21:22:25 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jason Zions)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:

>In article <[e-mail]> [e-mail]
>(Dave Cline) writes:
>>I believe current SVR4 is not compatible with the current P1003.2 draft.

>Another way to phrase that is that draft IEEE Std 1003.2 does not
>reflect existing UNIX practice.

Doug, you know *much* better than that. By this argument, ANSI C didn't
reflect any one implementor's existing practice either.

Or were you repeating the AT&T party line, i.e. "If it's not SVRx, it's not
UNIX"? In that case, POSIX was never intended to reflect solely UNIX
practice; it was intended to reflect concensus practice of a variety of
implemented operating systems bearing a family resemblence to UNIX.

Jason Zions
Chair of, but not speaking for, IEEE P1003.8

[ I thought Doug was pointing out some of the difficulties with "standard
  *nix," as well as problems with standards committees inventing things.
  Doug's comment can be applied to almost every UNIX(tm) and UNIX-like
  vendor around, since things were added to the 1003.2 standard-in-progress
  which don't necessarily exist elsewhere.  Some claim this to be necessary,
  good, and worthwhile; others think it is bad and should be discouraged.
  Just a point -- mod ]

Volume-Number: Volume 25, Number 101

From [e-mail]  Sun Nov 17 19:06:41 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13151; Sun, 17 Nov 91 19:06:41 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12507; Sun, 17 Nov 91 19:06:29 -0500
Newsgroups: comp.std.unix
From: Andrew Josey <[e-mail]>
Subject: XOPEN-testing mailing list
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Sat, 16 Nov 1991 12:04:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Josey)

This is to announce the creation of the xopen-testing mailing
list.  The intent is to provide a forum for discussion
of issues related to testing systems for conformance
to the X/OPEN Portability Guide (XPG), including Issue 3 (XPG3)
and later (Issue 4 is due out in mid-1992).

The scope of this newsletter is the discussion of items
associated with the testing of the X/Open Portability Guide - including
but not limited to test suite technology (X/Open's VSX and other
third party test suites for the XPG), latest news on X/Open
Branding and other related issues. These issues can include problems
related to test suites in general, testability of various features
of the XPG, and portability of the test suites.

Where discussions stray into general standards issues, I
will try to redirect them to the appropriate venues, such
as the comp.std.unix news group or the POSIX mailing list.

I reserve the right to exclude submissions that are in bad taste,
contain proprietary information, or are outside the scope of the
list as described here. The list will be distributed in digest form
at regular intervals.

To submit articles to the list email:

 [e-mail]


To subscribe to this newsletter email:

  [e-mail]


Note that mail to [e-mail] or to my personal
mailbox will not be re-distributed unless it contains a specific
request to do so.

--
Andrew Josey <[e-mail]>  (uucp: ...!uunet!uel.co.uk!andrew)
UNIX System Laboratories Europe Ltd, London, UK. Tel: [phone]


Volume-Number: Volume 25, Number 102

From [e-mail]  Sun Nov 17 19:06:43 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13156; Sun, 17 Nov 91 19:06:43 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12523; Sun, 17 Nov 91 19:06:31 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 17 Nov 1991 00:02:11 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

[e-mail] (Jason Zions) writes:

>In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
[...]
>>>I believe current SVR4 is not compatible with the current P1003.2 draft.

>>Another way to phrase that is that draft IEEE Std 1003.2 does not
>>reflect existing UNIX practice.

>Doug, you know *much* better than that. By this argument, ANSI C didn't
>reflect any one implementor's existing practice either.

>Or were you repeating the AT&T party line, i.e. "If it's not SVRx, it's not
>UNIX"? In that case, POSIX was never intended to reflect solely UNIX
>practice; it was intended to reflect concensus practice of a variety of
>implemented operating systems bearing a family resemblence to UNIX.

Let's face it: SVRx is not a standard, it's a non-standard.

Every vendor i've come along who said "I'm SVID compliant" has shown to
me the most cruel stabbings to what the original unix spirit was.

Typical example: the /etc/rc and /etc/rc.local script to fire up
multi-user mode.

seems SVRx has buried this once simple and easy-to-manage concept
into directories like /etc/rcN.d.

SGI has cast more weirdness into this with their /etc/config.

HP-UX thinks "/etc/checklist" is a better name for /etc/fstab.

STARDENT thinks "/etv/vfstab" would be an even better name for HP's
"/etc/checklist"; claims SVR4 but hasn't come up with a way to
use the DNS.

I will not even try to say anything about AIIII!!!X.

/* */

I run a machine where rc.local is 184 lines long; this machine runs
news, PP (a smtp/X.400/uucp/MAIL-11 gateway), quipu (an X.500 directory
server). 184 lines is something i would suppose that even a very dumb
sysadmin could cope with.

/* */

And while I'm at it - please: name me a "SVRx-compliant" system that can run:

- perl.
- X11R5, wcl, aXe.
- C-news, nntp, nn, rn, trn, xrn, gnus.
- less, traceroute, tcpdump, nfswatch.
- gcc, bison, flex, emacs, TeX.
- ISODE, PP, quipu.



Then, start your next round of "standartisation" again.


+-----------
  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland
  [e-mail]                 - terible simplifieur
  /s=karrer/ou=bernina/o=ethz/prmd=switch/admd=arcom/c=ch/


Volume-Number: Volume 25, Number 103

From [e-mail]  Sun Nov 17 19:06:48 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13163; Sun, 17 Nov 91 19:06:48 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12533; Sun, 17 Nov 91 19:06:37 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 16 Nov 1991 22:00:05 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

Maarten Litmaath writes:
> Doug Gwyn writes:
> > Dave Cline writes:
> > > I believe current SVR4 is not compatible with the current P1003.2 draft.
> > Another way to phrase that is that draft IEEE Std 1003.2 does not
> > reflect existing UNIX practice.
> Indeed, it does not reflect any of all existing _flavours_ of UNIX
> practice in full, so what?  Would you rather have a minimal standard
> that would guarantee no shell script to be portable that does anything
> beyond the complexity of "echo hello world"?

If that's the state of standardization of the current market, then yes.
Letting POSIX control UNIX is like turning the United States President
into a dictator with absolute power to make the law.

What makes standard-writing so attractive is that it strokes your ego.
You get to write down your musings about how the world should work, and
boom! Everyone does what you say. You don't have to waste time actually
*implementing* your ideas, or working out the problems, or competing
with people who were foolish enough to try their non-POSIX-approved
products on the market. You've got an _ego standard_.

This psychological explanation may sound a bit nasty, but it explains a
lot. It explains why POSIX members react emotionally to any hint that
their standards don't reflect the real world or are technically
inferior. It explains why no POSIX ``standard'' describes the state of
any actual system at the time of standardization. It explains why POSIX
people are so incredibly enthusiastic about writing standards, when in
the real world writing a standard means drudging through existing
documentation and rehashing it in the dullest possible language.

I wish POSIX would stop shooting off into the cosmos, come back to
earth, and spend some time documenting what UNIX systems actually *do*.

---Dan


Volume-Number: Volume 25, Number 104

From [e-mail]  Sun Nov 17 19:06:54 1991
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13170; Sun, 17 Nov 91 19:06:54 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12549; Sun, 17 Nov 91 19:06:43 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 17 Nov 1991 03:41:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>>Another way to phrase that is that draft IEEE Std 1003.2 does not
>>reflect existing UNIX practice.
>[ I thought Doug was pointing out some of the difficulties with "standard
>  *nix," as well as problems with standards committees inventing things.
>  Doug's comment can be applied to almost every UNIX(tm) and UNIX-like
>  vendor around, since things were added to the 1003.2 standard-in-progress
>  which don't necessarily exist elsewhere.  Some claim this to be necessary,
>  good, and worthwhile; others think it is bad and should be discouraged.
>  Just a point -- mod ]

I wasn't promoting any "AT&T party line"; however, for the information of
all you Berkeleyites out there who don't read the trade journals, SVR4
did manage to merge into a single system essentially all major UNIX
variants and thus should certainly be considered a base model for POSIX
standardization, as it was for X/Open for example.  No, what I was really
complaining about is the large amount of committee invention in 1003.2,
especially such atrocities as "c89", the regular expression mess, and a
rash of commands and options not previously implemented in ANY version of
UNIX.  I (and many others) worked hard for YEARS to eliminate or at least
minimize the variations between different versions of UNIX, culminating
in SVR4 (which is a fine base for further improvement).  The LAST thing
we need at this point is to start another incompatible variant of UNIX.

If you really want to know what I think would be appropriate for 1003.2,
go back and read my command/option set proposal made to 1003.2 years ago.
It spelled out exactly what *I* as a provider of portable software would
want in a UNIX environment to which I'm porting software.  It was much
smaller and cleaner than the last 1003.2 proposal I saw..


Volume-Number: Volume 25, Number 105