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

Internet Message Format | 1993-07-15 | 358KB

From [e-mail]  Thu Mar 11 14:25:05 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12761; Thu, 11 Mar 93 14:25:05 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16374; Thu, 11 Mar 93 14:24:27 -0500
From: Sean Eric Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2002
Date: 11 Mar 1993 11:17:34 -0800
Reply-To: [e-mail]
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 31 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Subject: Topic.

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

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

Subject: Moderator.

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

Subject: Disclaimer.

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

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


Subject: Postings.

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

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

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

If you are on the mailing list, and articles are bounced back to me from
your address, you will be deleted from the list, and I will attempt to
get in touch with the administrator for your site, or what looks like your
site, and will reinstate your presence on the list when the problem is
fixed.

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

Subject: Archives.

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

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to ftp.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.31
The previous volume, which is compressed, may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.30.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 or bash.

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

These files are updated rather sporadically; essentially, whenever
I come across this section at the beginning of each volume.

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


Subject: General submission acceptance policy.

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

As moderator, I reject relatively few articles:  maybe 1 out of 10;
although that amount varies, it is a good rough estimate.  I retain the
right to reject submissions.  If a submission does not appear relevant
to comp.std.unix, it is sent back to the submitter 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 submitter 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.  The most common response from me when I reject a submission
is to suggest that it belongs better elsewhere, usually some vendor-,
machine-, or operating system-specific newsgroup.



Subject: Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of four 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 occurs, and you think you may
    submit an article again, send me a note, and I will attempt
    to use an address you suggest next time.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.

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

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

Also, signatures that are excessively long may be truncated.  See
Gene Spafford's articles in news.announce.newusers for guidelines on
signatures.



Subject: Comments

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

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

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

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

Subject: Typographical

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

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

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

I don't have any reallly strict policies on formatting, but, in general,
if an article has overly-long lines, or the author has right-justified
the margins, I will run it through fmt(1) before posting it.  See
Gene Spafford's articles in news.announce.newusers for guidelines on
formatting of news articles.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened, and
``standard'' inclusions indicators of '>' are replaced, if the author
has used some other form.



Subject: Common kinds of postings.

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

Calendar of UNIX-Related Events

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

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

USENIX Standards Watchdog Reports

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

EUUG/USENIX ISO Monitor Project

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

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

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


Volume-Number: Volume 31, Number 1

From [e-mail]  Thu Mar 11 16:38:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24452; Thu, 11 Mar 93 16:38:07 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08894; Thu, 11 Mar 93 16:37:57 -0500
From: Roger Collins <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Conflict between .1 and .4a?
Organization: Encore Computer Corporation
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2005
Date: 11 Mar 1993 12:33:08 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Roger Collins)

[e-mail] (Mike Wulkan) writes:
>In .1 section 3.3.1.2 it says:
>  "If the action associated with a blocked signal is anything other
>  than to ignore the signal, and if that signal is generated for the
>  process, the signal shall remain pending until either it is unblocked
>  or the action associated with it is set to ignore the signal."
>To me this implies that a synchronous signal, such as a hardware fault,
>would not be held pending if it is blocked, because it was not generated
>for the process.

I disagree.  In .1 there is no concept of thread, so any signal to that
thread or process is "for the process."

>However in .4a 8.3.3.2 it says:

>  "Signals which are generated by some action attributable to a particular
>  thread, such as a hardware fault, shall be delivered to the thread that
>  caused the signal to be generated."
>  ...
>  "If the receiving thread has blocked delivery of the signal, the
>  signal remains pending on the thread until the thread unblocks
>  delivery of the signal or the action associated with the signal is
>  set to ignore the signal."
>.4a seems to have disregarded the difference between an asynchronous
>pthread_kill() and a synchronous signal, such as a hardware fault.

Yes, I'll agree with this.

>Unless I'm missing something, it would seem that .1 and .4a are
>incompatible with regards to keeping or not keeping synchronously
>generated (blocked) signals pending.

No, I think it is consistent when you allow for the loose usage of
process in .1 because there is no thread concept in that standard.
Synchronous and asynchronous signals should stay pending (until blah
blah blah).

>Can someone tell me what the "correct" interpretation is?

That's *my* interpretation -- better than correct. :)

Roger Collins


Volume-Number: Volume 31, Number 4

From [e-mail]  Thu Mar 11 16:38:08 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24457; Thu, 11 Mar 93 16:38:08 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08896; Thu, 11 Mar 93 16:37:59 -0500
From: Hal Jespersen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Posix.2
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2004
Date: 11 Mar 1993 12:31:15 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Hal Jespersen)

[e-mail] (Jeffrey S. Haemer) writes:
>David Rowley <[e-mail]> reports on the January 11-15
>meeting in New Orleans, Louisiana:
>
>POSIX.2 is equivalent to    the International Standards
>Organization's ISO DIS 9945-2 --    the second volume of the
>proposed    ISO three-volume POSIX standard.

Actually, for you technical editing groupies out there, I have proposed
to WG15 that we leave 9945 as two volumes--system API and shell & utilities--
and start a new ISO number for system admin (POSIX.7).  That new number
will be in multiple parts (xxxx-1, xxxx-2, etc.), corresponding to the
multiple parts of 1003.7.  This generated no opposition in October and I
have not received negative feedback from any of the national bodies, so
I assume we will approve this in May.

Hal Jespersen
WG15 Project Editor

Volume-Number: Volume 31, Number 3

From [e-mail]  Thu Mar 11 16:38:17 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24467; Thu, 11 Mar 93 16:38:17 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08944; Thu, 11 Mar 93 16:38:05 -0500
From: Simon Patience <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Conflict between .1 and .4a?
Organization: Open Software Foundation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2006
Date: 11 Mar 1993 12:34:29 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] (Mike Wulkan) writes:
>Unless I'm missing something, it would seem that .1 and .4a are
>incompatible with regards to keeping or not keeping synchronously
>generated (blocked) signals pending.
>Can someone tell me what the "correct" interpretation is?

I think the problem is that lines you first quote above are not as clear
as they could be. The "shall be delivered to the thread that caused the
signal to be generated" means immediately, regardless of the blocking
state etc, as in .1. There was no intention in .4a to change any of the
synchronously generated signal semantics from what is specified in .1.
The second paragraph is only intended to be relevant to signals
asynchronously generated, eg using pthread_kill() or alarm().

Simon.

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


Volume-Number: Volume 31, Number 5

From [e-mail]  Thu Mar 11 16:38:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24482; Thu, 11 Mar 93 16:38:28 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09006; Thu, 11 Mar 93 16:38:13 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: test method
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2003
Date: 11 Mar 1993 12:29:14 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Jeffrey Kegler)
writes a lot of good stuff about test-methods.

And lest anyone think he's crying wolf, the crippled POSIX subsystem
described in Windows NT literature should be enough to show otherwise.
But if that's not enough, I've run into situations where a vendor has
implemented a device driver in such a way that some features are totally
useless, and refused to fix them because they still conformed to the
SVID. For example, a serial driver that would not let you raise DTR
after dropping it, either by closing it and reopening or by setting
B0 and then B2400, since the SVID didn't specify that you be able to
raise DTR again except by doing a "first open" with no control terminal.

The technical people at this vendor agreed the implementation was broken,
but weren't allowed to fix it because the SVID didn't explicitly say
that anything else was required.

--
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U`
Sugar Land, TX  77487-5012 USA
[phone]                            "Zure otsoa besarkatu al duzu gaur?"

Volume-Number: Volume 31, Number 2

From [e-mail]  Thu Mar 11 16:38:30 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24489; Thu, 11 Mar 93 16:38:30 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09036; Thu, 11 Mar 93 16:38:18 -0500
From: Roger Collins <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX .4 signals
Organization: Encore Computer Corporation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2007
Date: 11 Mar 1993 12:35:15 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Roger Collins)

Do signals preempt a user's signal handler?

In other words, you're in a user signal handler, a signal is delivered
which is caught and unblocked, does it preempt the currently running
signal handler to run the signal handler for the new signal?  if it
is a lower numbered signal?


Volume-Number: Volume 31, Number 6

From [e-mail]  Fri Mar 12 17:05:14 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10341; Fri, 12 Mar 93 17:05:14 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16922; Fri, 12 Mar 93 17:05:05 -0500
From: Jeffrey Kegler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2011
Date: 12 Mar 1993 13:58:00 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey Kegler)

Based on the headers, I have to assume Bob Bagwill's response was
to my posting.  I could not have determined this from the message
body, because it does not address any issue which I addressed.

Bob Bagwill makes the point that test suites are A Good Thing.
I agree with this, and find his arguments solid.

My posting argued that test method *STANDARDIZATION* is harmful.
Bob doesn't address this issue at all.

Perhaps being assumed, without explicit statement, is this:
"Test Suites are Good, Standards are Good, therefore Test Method
Standards must be Good."  It's one of those assumptions which
doesn't survive explicit statement very well.  It's more a leap
of faith, than a chain of argument.  I accept both premises,
but find the conclusion totally without foundation.  Test Method
Standards require their own separate justification, and I feel
it unlikely that one can be supplied.

--
Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail] or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087

Volume-Number: Volume 31, Number 10

From [e-mail]  Fri Mar 12 17:05:47 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10398; Fri, 12 Mar 93 17:05:47 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23993; Fri, 12 Mar 93 17:05:43 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: test method
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2009
Date: 12 Mar 1993 13:52:22 -0800
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] (peter da silva) writes:
>
>In article <[e-mail]> [e-mail] (Jeffrey Kegler)
>writes a lot of good stuff about test-methods.
>
>And lest anyone think he's crying wolf, the crippled POSIX subsystem
>described in Windows NT literature should be enough to show otherwise.

I don't see why Microsoft's POSIX.1-in-a-box implementation
should serve as an indictment of test methods standards.
There's no reason to believe that it won't conform to the
letter of the POSIX.1 standard.  It's not productive to
say "I know POSIX when I see it, and this ain't it".

>But if that's not enough, I've run into situations where a vendor has
>implemented a device driver in such a way that some features are totally
>useless, and refused to fix them because they still conformed to the
>SVID.

The POSIX.3.1 test methods were never intended to be all-
encompassing tests of the quality of POSIX.1 implementations.
They were written to enable vendors to demonstrate that
their systems provide standard interfaces that allow developers
to port their code readily.

>For example, a serial driver that would not let you raise DTR
>after dropping it, either by closing it and reopening or by setting
>B0 and then B2400, since the SVID didn't specify that you be able to
>raise DTR again except by doing a "first open" with no control terminal.

Peter, are you indicting the SVID or the SVVS?  The SVID
is a specifications document like POSIX.1, and the SVVS
implements test methods for verifying SVID compliance.

The task of weeding out systems that don't provide adequate
usability belongs in the marketplace, not solely in the
standards arena.

--

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


Volume-Number: Volume 31, Number 8

From [e-mail]  Fri Mar 12 17:05:57 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10412; Fri, 12 Mar 93 17:05:57 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24090; Fri, 12 Mar 93 17:05:58 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2008
Date: 12 Mar 1993 13:49:04 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Bob Bagwill) writes:
>In the absence of a test method (and, presumably test assertions)
>what does it mean to "come as close as possible to the original
>standard"?
>1) Don't implement.  Buy the product from the original inventor.
>2) Implement, but use the inventor's test suite.
>3) Implement using the paper standard,
>   and use lawyers to "prove" that your implementation meets the standard.

4) Implement, using the most popular and widely available implementation
   of the standard as a guideline to cover the inevitable gaps in anything
   as complex as this. Honestly attempt to produce as versatile a system
   as possible under these constraints. Use feedback from your customers
   and competitors to improve the quality and conformity of your system.
   Amdahl and Digital Research have been pretty successful using this
   method without even having a paper standard to work from. Coherent and
   Eunice have carved out appropriate niches using this, again without
   even having a standard when they were first released.

A standard is not a spec for a product. If a company is (for whatever reasons)
using it as such, test assertions won't do anything but lower the actual
quality of the resulting product. If a company is making an honest attempt
at producing the best possible product they can afford to that meets the
requirements spelled out in the standard, the market will tell.

--
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U`
Sugar Land, TX  77487-5012 USA
[phone]                            "Zure otsoa besarkatu al duzu gaur?"

Volume-Number: Volume 31, Number 7

From [e-mail]  Fri Mar 12 17:11:34 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10809; Fri, 12 Mar 93 17:11:34 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26021; Fri, 12 Mar 93 17:11:35 -0500
From: Massimo Cotrozzi <[e-mail]>
Newsgroups: comp.std.unix
Subject: What about .6
Organization: Computer Science Dep. - Milan University
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: How is .6 work going ?
Keywords: .6 security
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2010
Date: 12 Mar 1993 13:54:00 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Massimo Cotrozzi)

What is the status of 1003.6?

--
Massimo Cotrozzi  Computer Science Dept. Milan Italy
[e-mail]  [phone]
#include     "std/disclaimer.h"

[ Wording changed slightly from Massimo's orignal -- mod ]

Volume-Number: Volume 31, Number 9

From [e-mail]  Sat Mar 13 18:43:33 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06670; Sat, 13 Mar 93 18:43:33 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18944; Sat, 13 Mar 93 18:43:30 -0500
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: perception of standards (was Even Good Test Method Standards...)
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2012
Date: 13 Mar 1993 15:40:33 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>>But if that's not enough, I've run into situations where a vendor has
>>implemented a device driver in such a way that some features are totally
>>useless, and refused to fix them because they still conformed...
>
>The POSIX.3.1 test methods were never intended to be all-
>encompassing tests of the quality of POSIX.1 implementations...

There is a problem of perception here, one that goes beyond just the
test-methods issue.  Some people view standards as laws, on the theory
that they establish the minimum that vendors should be allowed to market.
>From this viewpoint, standards should be as strict as possible, to raise
the quality of marketed software.

The problem with this view is that there is nobody standing over the
average vendor with a gun, forcing him to comply with the standard.
If it is too strict, he will simply ignore it.  Standards that are
not accepted are a useless waste of everyone's time.  (Nobody has
ever used ANSI standard EBCDIC -- certainly not IBM!)

The standard-setting process reflects this, by being organized so that
standards (in principle) represent consensus opinion of all concerned,
and so that (in theory) one group cannot ram a problematic standard
down everyone else's throat.  While disgruntled users may *want* to
ram some standards down the vendors' throats, that isn't the way the
standards process usually works... and when it does, you don't want
to be standing too close, because the result is likely to be a mess.

Standards developed by this process are best viewed as contracts,
telling each party what the other one promises to do and not to do.
And even a signed-and-sealed contract is not a substitute for good
will on both sides.  If you try to write an airtight contract, you
will end up with something that few people will sign, with eventual
litigation over details almost guaranteed.  (And the courts will
interpret such a contract very narrowly -- if you fail to fulfill
*your* obligations in the slightest detail, you can forget it.)
In practice, you are better off with something shorter and simpler
that doesn't try to seal every loophole.  This means you have to
pick a supplier who will live up to the spirit of his obligations
and not just the letter... but you have to do that *anyway*, because
there are *always* ways for him to fulfill the letter but not the
spirit.

The *only* way to keep vendors honest is competition.  Standards are
certainly useful in establishing what the vendors should be living
up to, but they won't make them live up to it.  If you don't want
to get shafted by a vendor, have an alternative vendor just in case.
This is what standards are really about -- giving you a stable base
so that you *do* have choices.

(The form of choice that I personally like best is having source code;
that way, if really necessary, I can tell the vendor to go spindle
himself, and make the fix myself.  There has historically been a problem
in that this was very expensive in the Unix world, outside some favored
enclaves like the universities... but that has changed.  You can now get
a decent exactly-like-Unix system, with full commercial support and
*WITH SOURCE*, for not much more than you pay for binary-only sludge
from the "UNIX is a registered trademark of <insert this week's name>"
people.  If you let yourself be locked into a monopoly supplier, it's
your own fault now.)

(To avoid leaving people dangling, I suppose I should say that if you
want to know more, send mail to [e-mail].  I don't work for
them, but I heartily approve of what they're doing.)

--
C++ is the best example of second-system| Henry Spencer @ U of Toronto Zoology
effect since OS/360.                    |  [e-mail]  utzoo!henry

Volume-Number: Volume 31, Number 11

From [e-mail]  Mon Mar 15 14:14:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22630; Mon, 15 Mar 93 14:14:41 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16392; Mon, 15 Mar 93 14:14:20 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: AT&T Bell Laboratories
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2014
Date: 15 Mar 1993 11:02:16 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

The problem with the test assertions analyses that I have
seen is that somehow there is confusion as to what the
real standard is.  In the case of POSIX.1, all implementations
must conform to the terms of 1003.1-19XX.  Any test assertion
that assumes more than this or something contradictory to
1003.1-19XX is broken.  The under-lying base standard always
prevails.  The interpretations process notably lies not within
any test methodology group, but within active and former members of
the 1003.1 committee who have participated in the development
of the base standard in question.  Any deviation in the Test
Methodology is routinely resolved in favor of the base standard.

What test methods are useful for, is for Test Implementors
to be able to eliminate the overhead of having to identify
independently all the requirements of 1003.1.  This also
presumably makes for more consistent testing vehicles.  If the
Test Methodology is missing things, this is a quality issue
and is in no way binding on an implementation.  Test suites
should include assertions based on 1003.1 whether or not the
methodology mentions it.  Test Suites may not test something
that is not specifically asserted in the base standard.

Perhaps this discussion really all boils down to the quality
of the test suite.


        Seth Rosenthal

Disclaimer: All opinions are my own not my employers'.


Volume-Number: Volume 31, Number 13

From [e-mail]  Mon Mar 15 14:14:55 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22652; Mon, 15 Mar 93 14:14:55 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16486; Mon, 15 Mar 93 14:14:37 -0500
From: Robin Fairbairns <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: U of Cambridge Computer Lab, UK
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2013
Date: 15 Mar 1993 11:01:09 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robin Fairbairns)

In article <[e-mail]>, [e-mail] (Jeffrey Kegler) writes:
Jeffrey Kegler argues that test method *STANDARDIZATION* is harmful,
and claims that Bob Bagwill doesn't address this issue at all.

He then goes on to argue about his reduction of Bob's comments to:
"Test Suites are Good, Standards are Good, therefore Test Method
Standards must be Good."

Let's back off a bit, and consider why people standardise at all.  If
you look in BS 0 ("A standard for standards"), they have a section
on the development of BS 1 on varieties of steel rail for railways;
this standard reduced the number of varieties on sale from something
like 70 to 5.  Customers were served well, but not as well as they
would have been by the writing of a perfect standard, in which all the
vendors had agreed on just one variety.  The lesson is that in an
imperfect world, even small steps towards perfection are of value.

Now, test methods are never (in non-trivial cases) going to indentify
all potential problems with an implementation.  And, in an imperfect
world, one is always going to have the rogue around who says "it runs
OK past the standard tests, therefore it's _right_".

But (as Peter da Silva suggests) it's next to impossible to remove the
rogues from the marketplace by standards, anyway.  So what's wrong
with pooling the effort of defining a basic set of test methods, and
then publishing that effort as a standard?

The legal position ought to help, too.  My experience of test
standards (NB, not within Posix) positions them as part of the
procurement process: if I want to buy something, I may require a
vendor to provide a conformance certificate that shows that his
implementation satisfies a set of test criteria.  But if I have a
problem with the implementation once I've bought it, my contract to
purchase had better be written in terms of the base standard -
otherwise I've exhausted all legal redress by requiring the
certificate in the first place.

--
Robin (Keep Radio 3 != Classic FM) Fairbairns       [e-mail]
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK


Volume-Number: Volume 31, Number 12

From [e-mail]  Mon Mar 15 20:31:48 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05408; Mon, 15 Mar 93 20:31:48 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15061; Mon, 15 Mar 93 20:31:50 -0500
From: Dave Cline <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2015
Date: 15 Mar 1993 17:23:50 -0800
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 article <[e-mail]>,
    [e-mail] (Jeffrey Kegler) writes:

>Here's the problem.  In the absence of a test method standard, the
>implementor of the base standard must come as close as possible to the
>original standard.

To be a bit more precise, in the absence of a conformance test suite,
the implementor must *say* they implement the base standard.  It's
not quite the same thing in the real world.

>If a test method standard exists, however, he need
>only implement to pass the tests in that standard.

Here, as in the following, no clear distinction is made between
a test method standard and a conformance test suite is made.

Conformance test suites existed long before anyone thought of
writing a test method standard.  Almost all of the arguments that
are advanced here against test method standards apply equally to
conformance test suites.

>Standardized test methods imply, perhaps paradoxically, a considerably
>less rigorous standard than their original base standard.  Almost all
>standards of POSIX complexity will contain requirements which are not
>practically testable.  The standardized test method, in effect,
>repeals these.
>
>The mathematical argument that the base standard implied by the test
>method standard must be less rigorous than the original is
>straightforward.  Most POSIX standards will specify a sufficiently
>complex system to implement a Turing machine.  Testing that all
>programs for a Turing machine correctly execute on a given black box
>is impossible, even in theory -- it implies the solution of whole sets
>of undecidable problems.

I think that the reference to Turing might have been intended to refer
to Goedel, but anyway, the reference is misplaced.   A Turing machine
requires infinite storage.  If only finite storage is present, then
one can, in theory, enumerate all the possible programs and their
results.  With finite storage there is no halting problem.  One may
well choose not to wait for the answers, though.  :-)

There are hard problems.  There are complex standards.  Exhaustive
black box testing of standards is not possible for many different
reasons.

All of these statements have nothing whatever to do with Turing machines.

Any black box test such as a conformance test suite samples only
a small portion of the potential state space of a large system.
As with any test, it can only show the presence of bugs.

We certainly should not criticize black box conformance testing
because it cannot show the absence of bugs.

>It would seem to me to be prudent to produce test method standards on
>a limited, trial basis, if at all.

It seems valid to argue against formal test method standards because:

  a) they are hard to write.
  b) they are just as error-prone as the original standard.
  c) there is no mechanical way to ensure that both standards
     say the same thing.
  d) they are not cost-effective.
  e) the audience for such standards is limited.
  f) they are not technology enablers.  Conformance test suites
     will be written even if test method standards are not.
  g) the time required to create a test method standard impacts
     the timely release of the base standards.

I agree with the above statements.

However, one should distinguish between test method standards
and conformance test suites.  The conformance test suites will
end up being written whether a test method standard exists
or not (e.g. languages have not been "blessed" with test method
standards, but language conformance testing is accepted industry
practice).

--

Volume-Number: Volume 31, Number 14

From [e-mail]  Tue Mar 16 01:02:24 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24528; Tue, 16 Mar 93 01:02:24 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22867; Tue, 16 Mar 93 01:02:20 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: test method
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2016
Date: 15 Mar 1993 22:00:31 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>I don't see why Microsoft's POSIX.1-in-a-box implementation
>should serve as an indictment of test methods standards.

That wasn't my intent... I was simply pointing out an example of how a
vendor can abuse a standard. Test method standards simply give many of
them something else to abuse.

>There's no reason to believe that it won't conform to the
>letter of the POSIX.1 standard.  It's not productive to
>say "I know POSIX when I see it, and this ain't it".

Again, that's putting words into my mouth. Yes, I'm sure it will satisfy
POSIX.1 to the last jot and tittle. It won't be terribly *useful*, but
that's not something that can be mandated by POSIX... it's a 'quality of
implementation' issue.

And leaving it to the marketplace isn't good enough, because the marketplace
by and large doesn't care about POSIX other than as a check-mark on a PR
form. If we leave it to the marketplace we're going to all be coding to the
Win32 "standard".

--
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U`
Sugar Land, TX  77487-5012 USA
[phone]                            "Zure otsoa besarkatu al duzu gaur?"

Volume-Number: Volume 31, Number 15

From [e-mail]  Tue Mar 16 15:23:12 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16395; Tue, 16 Mar 93 15:23:12 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28983; Tue, 16 Mar 93 15:23:04 -0500
From: Andy Feibus <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2017
Date: 16 Mar 1993 12:12:15 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andy Feibus)

[e-mail] (Dave Cline) writes:
> It seems valid to argue against formal test method standards because:
>
>   c) there is no mechanical way to ensure that both standards
>      say the same thing.
Taking this a step further, a test methods standard may not provide
complete or completely correct test coverage of a standard.  Following
from that (I hate the words "hence" and "thus" :-), a test suite based
on the test methods standard may not properly test the actual technology
it intends to verify.

So, if a test suite is only an implementation of the test methods standard
and the test methods standard may not completely or correctly test the
technology, what good is it?  Even better -- or, more confusing --
how do we verify that the test suite is a complete and correct
implementation of the test methods standard (which may or may not be
complete or correct)??

-- Andy.

------------
Andy Feibus.
Open Systems Today; SCO Magazine
[e-mail]

Volume-Number: Volume 31, Number 16

From [e-mail]  Tue Mar 16 20:05:38 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07948; Tue, 16 Mar 93 20:05:38 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03161; Tue, 16 Mar 93 20:05:24 -0500
From: David Emery <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: The Mitre Corp., Bedford, MA.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2018
Date: 16 Mar 1993 17:01:25 -0800
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 Emery)

An issue that many people forget is that there is no such thing as a
test suite against a (language-independent) interface.  All test
suites are written in a programming language, and therefore test the
programming language binding (C, FORTRAN, Ada, Esperanto, whatever.)

If you have language-independent interface specifications, then test
assertions against that LI specification might make sense.  If you are
testing a language binding, then I see no reason for worrying about
test assertions.  Instead, write the actual test, in the programming
language.  This avoids the issue of whether a test suite correctly
implements the assertion.  In the case of the current POSIX.1
standard, we have test assertions against a C language binding.  I
don't find this very useful.

The Ada compiler tests (Ada Compiler Validation Facility) are freely
available.  They are used by implementors to test/debug their
compilers, by (suspicious) users to make sure that the compiler meets
the test, and by the Ada validation facilities (worldwide) to validate
Ada compilers against the DoD validation criteria.  They are
maintained by the Ada Validation Office, and the number of ACVC tests
has at least doubled since its inception, as new tests are developed
to validate parts of the language, and interactions between language
features, that were not included in previous tests.  Contrast this to
the POSIX approach, where the assertions (of no practical use to
anyone except a test developer) are open, but actual test suites are
proprietary to the test labs.  And, in POSIX, the test assertions have
the same development/modification/interpretation/improvement overhead
as the basic POSIX.1 standard, making it very hard to add new
tests/assertions as we learn more about testing POSIX compliance.

Frankly, I think the time and effort would have been better spent
developing actual C test suites for POSIX conformance, rather than
spending all of that time developing test methods that require
translation into C to be of any practical use to anyone besides a test
suite developer.  This might put some test suite developers out
of business, but it would be much more useful for the community as a
whole.
                dave


Volume-Number: Volume 31, Number 17

From [e-mail]  Wed Mar 17 14:54:03 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06373; Wed, 17 Mar 93 14:54:03 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24585; Wed, 17 Mar 93 14:53:48 -0500
From: Mike Wulkan <[e-mail]>
Newsgroups: comp.std.unix
Subject: alarm()ing semantics
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2019
Date: 17 Mar 1993 11:07:42 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In POSIX.4a 8.3.3.2 it says:

  "Signals which result as a result of an alarm() call are directed at
  the thread that requested the alarm."

but in 8.4.4.2 it says:

  "The SIGALRM signal is asynchronously delivered to the process as a
  result of calling alarm()."

Which is it, the thread or the process?

I guess thread, or there wouldn't be much point in having section 8.4.4.2
rather than just refer to POSIX.1.

Mike Wulkan

Volume-Number: Volume 31, Number 18

From [e-mail]  Wed Mar 17 17:30:17 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24282; Wed, 17 Mar 93 17:30:17 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09804; Wed, 17 Mar 93 17:30:03 -0500
From: Jeremy Epstein <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX security: call for participation
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2020
Date: 17 Mar 1993 14:09:46 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeremy Epstein)

POSIX 1003.6 (Security) Working Group Organizing New Subgroups
==============================================================

For the past year, the P1003.6 Working Group has been focused on resolving
ballot objections to the current draft standard.  Starting at the April
meeting in Irvine, several new subgroups will be formed to investigate
the development of standard security interfaces for additional functional
areas.

At the P1003.6 meeting in New Orleans in January, the group came up with a
list of potential areas where work could be performed.  Note that this list
is not necessarily exhaustive.  It is simply a starting point.  The actual
areas to be worked will be determined, to a large degree, by the wishes of
the people who show up to do the work.  If you have a specific area of
interest, you are strongly encouraged to start attending the meetings on a
regular basis, starting with the April meeting.  Those of us who have
participated in the group over the last few years have found the work
interesting and rewarding.  Our companies, who have sponsored our
attendance, have also found our participation to have significant value.

The current draft would not be coming to fruition were it not for the work
of all those who have participated in the Security Working Group (1003.6) -
a dedicated group of individuals representing many different technical
viewpoints.  If you are a member of that origina  group, we welcome you back
as we start our new efforts.  If you have not participated before, but have
an interest in any of the topics below, or any other related topic, we
also welcome your participation.  The broader our base of expertise and real
world experience, the better the resulting standard will be.  Your efforts
will make a difference.

This working group is known for working hard, and playing hard.
It is a group dedicated to the development of security interfaces.
Although the meetings can be lively with contentious technical discussion,
the group also has been known to have fun together. You too can
become a part of the group that introduced the Bunny Hop to an unsuspecting
Europe; was remembered by the staff at a major hotel the next year ("Are THEY
here again???"); was observed at the bar in the Holiday Inn at 1AM with
4 notebooks plugged in, working on the draft; as well as many other
moments too numerous to be recounted here.  P1003.6 is a very active group,
strongly committed to the standards process, very receptive to new members
and new ideas, working together well as a team.

If you have any further questions about the working group or the upcoming
meeting, please contact the Acting Vice Chair, Lynne Ambuel [phone].
She can also be reached electronically at Ambuel @ dockmaster.ncsc.mil.

We hope to see you in Irvine!!

List of Potential New Functional Areas
======================================

Administrative Services
          Administrative user interfaces to security-related mechanisms is
          an area that was specifically determined to be "out-of-scope" for
          the original 1003.6 effort.  However, the group understands that
          this is an area that needs to be standardized so that an
          administrator's interface to portable systems is predictable and
          well-defined.  The Security Group (1003.6) met with the
          Administrative Services group (1003.7) to discuss possible
          overlapping areas on which security attributes should be handled
          in their proposed user database.  After a period of discussion, it
          was agreed upon that some kind of liaison should be established
          between the Security and Administrative Services Groups
          The possible security administration areas that could be addressed
          are listed below:

          Password Management
          Backup/Restore
          Audit
          Privilege/Authorizations
          MAC
          Information Labels
          Label Management
          Process Management
          Job Control Management
          Resource Management
          User/Login Management - User Accounts
          Terminal Management - Session
          I&A Management
          System CM
          ACL Management
          Role Management
          Clearances
          Device Management
          Software/OS Installation


General Cryptographic Services Interfaces
          Generic interfaces to cryptographic services was not
          within the original scope of the 1003.6 effort.
          However, there were specific ballot objections to Draft 12
          of the standard because it did not include any such
          interfaces. The ballot resolution group agreed that the
          interfaces are needed and that they should be addressed.

          A balloter has provided a series of interfaces for checking
          the integrity baseline of a system and for generating
          and verifying digital signatures.  This 'proposal' could be
          used as a basis for developing the interface for
          cryptographic services.

          Encryption was also considered to be of importance in
          cryptographic services.  This would include interfaces
          to keying algorithms, as well as encryption and decryption services.
          The emphasis would be on a creating generic algorithm-
          independent API.

          A major problem with dealing with standardization of
          cryptographic services at an international level is
          import and export restrictions on cryptographic services
          and algorithms.  This is true not only between US and
          Europe, but also between national boundaries within Europe.
          However, the feeling is that these trade barriers seem to
          be weakening and this effort is therefore a worthwhile one.

Identification and Authentication
          Identification and Authentication (I&A) was identified as
          being out of scope in draft 12 of the 1003.6 document.
          However, it is acknowledged by the members of 1003.6 that
          I&A is an integral part of protection mechanisms and should
          be considered. UNIX login, for example, is widely used and
          should be included in the IEEE POSIX API. I&A was considered to
          be one of the most important  new work items by virtually all of
          the members present at the New Orleans meeting.
          Thus, I&A will most likely become a new work item
          for the 1003.6 group. In addition, discussions with the
          Administrative Services group identified I&A management as
          a security service with security attributes.

          Topics to be considered under I&A include:
          * Credential Management - Identification and maintenance of
            credential information needed for proper identification of
            a user.
          * Credential Manipulation - Modification, duplication and
            delegation of credentials of a user.
          * Passwords - Passwords were reluctantly added to the list,
            not because they are not important but because of the fear of
            establishing a standard that would be bound to a password
            mechanism.  It was the opinion of the group that FIPS 112
            should be looked at for ideas and direction.  In addition,
            the UK government password guidelines could be used as
            input to this effort.
          * Additional Authentication - Additional authentication mechanisms
            should be identified and researched.  (e.g. smart cards,
            biometrics, etc.) However, the group would concentrate on
            developing APIs to these mechanisms without setting a
            standard as to which one should be used.
          * Identifier Management (User) -  Identification and maintenance
            of information needed to properly identify a user are to be
            included in this effort. Items such as name, clearance,
            organizational code could be considered along with any other
            information that could be used to determine security related
            privileges of a user.

Security Liaison Efforts
            The original scope of P1003.6 included adding new interfaces
            for security-related functions to P1003.1 and P1003.2, as
            well as redefining those interfaces within P1003.1 and
            P1003.2 that provided security vulnerabilities for
            complying systems.  The latter portion of this scope now needs
            to be extended to the other IEEE POSIX standards that are
            being developed, to be sure that there are no inherent
            security flaws in those systems.  In order to accomplish
            this task, the IEEE P1003.6 Security Working Group sees it
            as very important to keep track of, and have an active
            liaison with, other POSIX working groups that have now, or
            in the future may have, security implications. An active
            dialog with these groups will lessen the possibility that
            any security flaws are mandated in systems developing to
            those standards.

            This includes the following:
               * 1003.1a extensions to ISO 9945-1:1990
               * 1003.2b ISO revision of 1003.2
               * 1003.4  real-time
               * 1003.4a threads
               * 1003.7  administration
               * 1003.8  transparent file access
               * 1003.12 protocol independent network specification
               * 1003.15 batch services
               * 1003.17 directory/name services

            The goals of this work are to ensure that security issues
            are either addressed directly by the affected working
            groups or brought to the attention of the security working
            group for inclusion at a later stage in the list
            of "new work items", as well as to ensure a better
            understanding of potential security issues in other
            specifications.  It is also important for the working group
            to understand the security impact of these other interfaces
            on the 1003.6 specification.

Networking Services
            The IEEE P1003.6 Security Working Group will investigate the
            development of security extensions for Networking Services.
            These extensions will work within the guidelines described in
            the evolving IEEE POSIX Distributed Security Study Group's
            proposal "A Distributed Security Framework for POSIX".

            The group will address security extensions and new interfaces
            to allow security services to function in a network or
            distributed system environment in the following  potential areas:

            * Secure RPC: interfaces need to be defined which allow for
              the selection of a variety of security services including
              identification, authentication, and possibly access control.
            * Authorization and Access Control: current authorization and
              access control interfaces should be extended to work within
              a distributed system environment.
            * Distributed Management Interfaces: interfaces should be
              defined to allow the management of the variety of security
              attributes and services necessary in a network or
              distributed system environment.
            * Auditing: extensions to the security auditing interfaces
              need to be defined to allow auditing to work in a network
              and distributed system environment. For example, the audit
              interfaces need to provide the ability for servers to audit
              events on behalf of the client. Likewise, the auditing
              interfaces need to provide services to  handle audit
              trails which may be spread across multiple systems.
            * Credential Management: interfaces should be defined to
              manage user credentials and their associated attributes
              in a network-wide or distributed system.

Portable Formats
            The IEEE P1003.6 Security Working Group will investigate
            the development of standard, portable formats for access
            control lists (ACLs), mandatory access control (MAC) and
            information labels, file privilege states, and audit trails.
            Developing standard, portable formats for ACLs, labels, and
            file privilege states is necessary to preserve security
            relevant attributes of objects when importing and exporting
            those objects between non-homogeneous (and sometimes even
            homogeneous) platforms. Developing a standard, portable
            audit trail format is necessary to preserve the usefulness
            of audit trails when importing and exporting audit data
            between non-homogeneous platforms.

            This effort will include interacting with other POSIX
            working groups that are developing standard interfaces
            that should utilize these portable formats.

**********************************************************************

AGENDA FOR IRVINE P1003.6 Security Working Group Meeting
========================================================

The IEEE POSIX Working Group for Security will meet at the Irvine
Marriott Hotel in Irvine CA during the week of 19 - 23 April. More
information about registration and attendance to the meeting can be
obtained from Brenda Williams at the IEEE Computer Society. Her telephone
number is [phone].  The telephone number of the conference hotel
is [phone].

The April meeting of Security working group (P1003.6) will have
two purposes: to resolve ballot issues for the current draft standard
and to define and begin formulating the new set of protection interfaces
for several functionality areas not encompassed by the current draft.
There will be both large group discussions and small group work sessions.

Mon, 19 April:    9:00-11:30  Discussion of the new interface areas.
                              Formulation ofnew subgroups.
                  1:00-2:30   Discussion of Liaison issues
                              Selection of liaisons to other working groups
                  2:30-5:00   subgroups meet

Tue, 20 April:    9:00-5:00   subgroups meet

Wed, 21 April:    9:00-5:00   Open discussion with Ballot Resolution Team
                              regarding significant changes to the draft
                              required to resolve ballot objections.
Thu, 22 April:    9:00-5:00   Ballot Resolution team meet to continue the
                              ballot resolution process.
                  9:00-5:00   Liaisons will meet with their target working
                              group.
                  9:00-5:00   subgroups will continue to meet.

Fri, 23 April:    9:00-3:00   Ballot Resolution team meet to continue the
                              ballot resolution process.
                  9:00-3:00   Liaisons will meet with their target working
                              group.
                  9:00-3:00   subgroups will continue to meet.
                  3:00-5:00   Closing plenary to discuss progress and to
                              task any work that needs to be done before
                              the July meeting. If this plenary is deemed
                              unnecessary, each of the above groups will
                              continue their own work.
************************************************************************

WEDNESDAY OPEN DISCUSSION ON 1003.6 BALLOT ISSUES

In the process of resolving ballots on the P1003.6 document, several
contentious technical issues have been raised that the ballot resolution
group feels should be brought before the working group as a whole. These
issues are ones initiated by some balloters and disapproved by other
balloters. The changes mandated by these balloters would fundamentally
change the technical basis on which the interfaces were written. The
following list is a sample of some of these issues. Other issues may also
be raised.  The ballot resolution group will lead this discussion and welcome
input from all those present, whether or not they are currently part of the
balloting group.

          1. A set of balloters have objected to the inclusion of specific
privileges in the standard.
          2. A set of balloters objected to the inclusion of the mask
mechanism in ACL section of the standard. The mask was removed from draft
13. A different set of balloters have now objected to the removal of the
mask from the specification.
          3. A set of balloters objected for the inclusion of multi-level
directories in the standard. These interfaces were removed from the standard
for the Draft 13 ballot. A different set of balloters have now objected
to the removal of multi-level directories.



Volume-Number: Volume 31, Number 19

From [e-mail]  Thu Mar 18 15:51:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02244; Thu, 18 Mar 93 15:51:40 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08693; Thu, 18 Mar 93 15:51:12 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2021
Date: 18 Mar 1993 12:48:25 -0800
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 Volume 31, Number 16, [e-mail] (Andy Feibus) wrote:
>[e-mail] (Dave Cline) writes:
>> It seems valid to argue against formal test method standards because:
>>
>>   c) there is no mechanical way to ensure that both standards
>>      say the same thing.
>Taking this a step further, a test methods standard may not provide
>complete or completely correct test coverage of a standard.  Following
>from that, a test suite based
>on the test methods standard may not properly test the actual technology
>it intends to verify.

At least if you there is a test methods standard, it's
possible to assess how  much coverage there is.  Where
there are test suites that are written as series of ad hoc
exercises for the implementation, there's no clear
specification against which the tests can be examined for
either completeness or correctness.

>So, if a test suite is only an implementation of the test methods standard
>and the test methods standard may not completely or correctly test the
>technology, what good is it?

It's a much better basis for verifying conformance than
we'd have otherwise.  I can pretty confidently guarantee
that without test methods standards we'd have less
confidence in our test suites and that implementations
would be tested less well than they are now.

Rather than compare the POSIX.1 testing situation with that
for ada, I find it instructive to consider the case of the
SVVS.  This test suite was written to test a somewhat
underspecified base document without formalizing the test
assertions.  The result was that the test suite itself
became the de facto standard, with no effective means for
review of its correctness.

>Even better -- or, more confusing --
>how do we verify that the test suite is a complete and correct
>implementation of the test methods standard (which may or may not be
>complete or correct)??

By reading them carefully, looking at the results when test
suites written to them are run, and correcting the test
suites and the test methods and the base specifications
when we find problems.  Just like any other software
product.

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

Volume-Number: Volume 31, Number 20

From [e-mail]  Sun Mar 21 22:11:51 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05485; Sun, 21 Mar 93 22:11:51 -0500
Received: from kithrup.com (via garth.kithrup.com) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22935; Sun, 21 Mar 93 22:11:48 -0500
From: Frans Meulenbroeks <[e-mail]>
Newsgroups: comp.std.unix
Subject: controlling tty questions
Organization: Philips Research Laboratories Eindhoven, Netherlands
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2022
Date: 21 Mar 1993 19:08:24 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Frans Meulenbroeks)

I'm trying to implement controlling ttys as specified in POSIX 1003.1,
but unfortunately the book is not very clear on what to do if
there is no controlling tty, and an open on /dev/tty is attempted.
My best guess would be to reject the open and return an errno.
If that is right, then what is the best errno value to return?
EACCESS??  If that is wrong, what else should be done?

Also, it is not quite clear to me what should happen if the controlling
tty is disassociated from the session, while a child process still
has a stream open to /dev/tty. The standard says that you should
behave as if a modem was disconnected, but what does that exactly
mean in operational terms (e.g. what happens with successive reads,
ioctls and writes; which error codes need to be returned etc.).

Any comment clearing up this matter is highly welcome.

Thanks,

--
Frans Meulenbroeks        ([e-mail])
    Philips Research Laboratories

Volume-Number: Volume 31, Number 21

From [e-mail]  Sun Mar 21 22:11:53 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05490; Sun, 21 Mar 93 22:11:53 -0500
Received: from kithrup.com (via garth.kithrup.com) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22936; Sun, 21 Mar 93 22:11:48 -0500
From: Jeffrey Kegler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Algorists, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2023
Date: 21 Mar 1993 19:09:39 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey Kegler)

In article <[e-mail]> [e-mail] (Dave Cline) writes:
>In article <[e-mail]>,
>    [e-mail] (Jeffrey Kegler) writes:
>
>>The mathematical argument that the base standard implied by the test
>>method standard must be less rigorous than the original is
>>straightforward.  Most POSIX standards will specify a sufficiently
>>complex system to implement a Turing machine.  Testing that all
>>programs for a Turing machine correctly execute on a given black box
>>is impossible, even in theory -- it implies the solution of whole sets
>>of undecidable problems.
>
>I think that the reference to Turing might have been intended to refer
>to Goedel, but anyway, the reference is misplaced.   A Turing machine
>requires infinite storage.  If only finite storage is present, then
>one can, in theory, enumerate all the possible programs and their
>results.  With finite storage there is no halting problem.  One may
>well choose not to wait for the answers, though.  :-)

An outsider comparing these two paragraphs will come away with the
impression that at most one of the writers really knows Theory of
Computation.  One or more knows the terms, some of the names, and even
some of the definitions, but does not understand how the field works.
This impression is correct.

Hackers despise people who drop names, fall back on credentials, etc.,
realizing that good credentials often back poor arguments, and good
arguments often come without strong credentials.  This trait is one of
the joys of working in the community of hackers.  Nonetheless, what we
have here is two people claiming understanding of a difficult field,
where the full explanations would take too much space.  I hope then
the following will be seen as appropriate and helpful.  I have
published a referreed article in Theory ("Technical Correspondence",
Communications of the ACM, June 1986, V29N6).  It went to press with
the change of one typo in my submitted draft.  (It would seem from
this test that it is considerably less hassle to publish new results
in CACM than trivial ones in comp.std.unix!)  I don't claim to be more
than an extremely minor figure in the Theory world.  I do claim to
know what I am talking about when I am careful to stick to the
mathematically trivial and obvious, as I did above.

More in the way of justification follows.  Those who know Theory of
Computation well with find nothing new here.  Those who never cared
about Theory will find nothing that should make them reconsider that
opinion.  To the extent they wish to give me further attention at all
they may jump to the conclusion at the end.  Those who do care some,
and would like to know more, may find their time rewarded.

1.  My reference to the Turing machine is boilerplate.  In order to
establish the relevance of the usual theorems, a result usually starts
by demonstrating equivalence to one of the usual theoretical models,
the Turing machine being the most common.  In theory, this
demonstration consists of a proof that the new computation model can
implement a Turing machine, and vice versa.  In practice, these facts
are usually so obvious that the technique I employed above, known as
"hand-waving", is all that is done.

The applicability of Goedel's undecidability results, and of a host of
others, is established via the Turing machine.

2.  Dave Cline is right when he says the Turing machine allows for
infinite space, in its quaint old model, using an infinite tape.  He
then attempts a demonstration of the irrelevance of any such model to
finite computation.  First off, let me point out, that since we are
discussing standards, not physical machines, so the matters under
discussion are all theoretical models.  Unless they specifically point
out that "no implementation shall be capable of simulating a Turing
machine with a tape containing more than 711 gigabits.", or
mathematically equivalent language, the standards are, in many cases,
Turing machine equivalent in the strict sense.

3.  But even taking the infinite/finite point as seriously as I just
did in the previous paragraph is very misleading.  If we accept that
Dave Cline's point was even potentially valid, it means that no
infinite model is relevant in application to actual, physical, finite
machines.  Big O notation is irrelevant for example.  Saying an
algorithm requires O(log n) time, as opposed to O(n), is meaningless
in real life.  The halting problem, as Dave points out, now can be
considered quite solvable.

Even stupid little finite state automata handle infinite inputs, so
they too must get the heave-ho.  So the math underlying regular
expressions is irrelevant as well.

Dave Cline takes issue, not with my use of Theory of Computation, but
with the basics of most of the field.

4.  Almost all mathematics of computation uses infinite models at some
point.  For that matter, accountants use the integers, of which there
is an infinite number, to represent dollars and cents, even though
none of their clients (except possibly the Federal Reserve) has access
to infinite funds.  This point is more than verbal trickery.  The fact
is that models implying infinity are used routinely in even low level
math, for extremely mundane and practical uses.

This did not come about without a good deal of debate.  The Greeks had
great trouble with the theoretical difficulties the use of infinity
implies.  The more practically minded Indian mathematicians just went
ahead and did it.  They resolved none of the theoretical difficulties,
but made great strides in practice, and our modern daily use of
arithmetic comes from India.  A solid theoretical underpinning to the use of
infinity did not come about until around 1900.

In short, Theory of Computation is based on models of computation
embodying potential infinities, just as engineering or accounting.

5.  Perhaps paradoxically, infinite models are almost always *more*
relevant to practice than finite ones.  Take Dave Cline's example of
the halting problem.  On a finite machine it's solvable by
enumeration, he correctly states.  On the real machine, however, which
does have potentially infinite time available, we must take into
account in counting space all the tapes we could mount, all the new
disks we could buy, all the storage we could access over a net and all
the technological improvements that might come along.  The infinite
tape winds up modeling the complexities of the real world as well or
better than any finite model -- and the math is easier, no small
consideration.

Take the argument that on your finite-sized machine the halting
problem is solvable (by enumeration, based on its finitude), and the
argument that the problem is undecidable -- which is the more
practical?  Anyone wishing to say the former is the more relevant
logic, could prove his case by contributing to the FSF a utility to
solve the halting problem [ or perhaps it could be a lint hack :-) ].

Conclusion: My brief essay into math was intended to make strongly the
point that many essential assertions contained in base standards are
not testable.  This point is one that one does not need Theory of
Computation to decide.  It's fairly obvious to anyone with a hackerly
bent.

In the rare cases where Theory can make an argument stronger, I like
to employ it.  It makes me feel my youthful studies were not entirely
in vain.  Those who don't care for Theory can safely skip the details,
leaping ahead to the result, and seeing it was pretty obvious without
all the BS.

Whether the argument is from Theory or Hackery, test method standards
*must* be watered down versions of the base standard.  No one has
argued this, not even those who appear to be willing to tilt their
lance at whole subfields of Comp. Sci.
--
Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail]
137 E Fremont AVE #122, Sunnyvale CA 94087
"Chairman Warren, if you felt your life was in danger at the moment,

[ I'm not sure this thread belongs in comp.std.unix anylonger -- mod ]

Volume-Number: Volume 31, Number 22

From [e-mail]  Mon Mar 22 14:49:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28717; Mon, 22 Mar 93 14:49:00 -0500
Received: from kithrup.com (via garth.kithrup.com) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20511; Mon, 22 Mar 93 14:48:55 -0500
From: Lee Schermerhorn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX .4 signals
Organization: Concurrent Computer Corp.  Westford, MA
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2024
Date: 22 Mar 1993 11:43:55 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Lee Schermerhorn)

>Submitted-by: [e-mail] (Roger Collins)
>
>Do signals preempt a user's signal handler?
>
>In other words, you're in a user signal handler, a signal is delivered
>which is caught and unblocked, does it preempt the currently running
>signal handler to run the signal handler for the new signal?  if it
>is a lower numbered signal?

Yes -- just as in Posix.1 signals -- handlers do nest.  It doesn't matter
whether the new incoming signal is a lower number or not.  If it is
unblocked (and caught) at the time of generation, it will be delivered.
The only new semantics that Posix.4 bring are:

1)  a specification of queueing of multiple occurences of a signal.  Posix.1
    leaves this implementation defined (1003.1-1990, sect 3.3.1.2, p.53,
    lines 463-464).

2)  a specification of ordering of delivery when more than one signal is
    pending an unblocked:  within the range of "realtime" signals defined
    by Posix.4, lower numbers are delivered first (the rationale explains
    why);  the order outside of the "realtime" range is unspecifed.  Posix.1
    left the ordering unspecified (op cit, lines 464-466).

3)  a specification of the delivery of additional signal information.
    This was essentially lifted from the SVR4 "siginfo" behavior, with
    the addition of an application defined datum that can be passed with
    the signal.

You might wonder if a subsequent occurence of a signal can preempt the
signal handler for the same signal, causing it to be reentered.  It could,
but only if the application explicitly unblocked the signal from within
the handler.  When the signal is delivered, its signal number is
automatically added to the process's current blocked signals mask.

Lee Schermerhorn
Concurrent Computer Corp
Secretary, P1003.4 WG
Technical Reviewer, P1003.4 various sections


Volume-Number: Volume 31, Number 23

From [e-mail]  Tue Mar 23 14:54:16 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07264; Tue, 23 Mar 93 14:54:16 -0500
Received: from kithrup.com (via garth.kithrup.com) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07560; Tue, 23 Mar 93 14:53:51 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: controlling tty questions
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2025
Date: 23 Mar 1993 11:36:37 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Frans Meulenbroeks) writes:
>My best guess would be to reject the open and return an errno.
>If that is right, then what is the best errno value to return?
>EACCESS?

I don't think a *device* should ever return EACCESS or (for that matter)
ENOENT. I've had *both* of them, and every time I (or the person I'm working
with) has gone scurrying around trying to figure out what file the program
was really trying to use. Why? Because almost always these errors *are* due
to some program calling perror incorrectly with the wrong name.

I would suggest ENXIO, EINVAL, or even ENODEV.

--
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U`
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
[phone]                            "Zure otsoa besarkatu al duzu gaur?"

Volume-Number: Volume 31, Number 24


From [e-mail]  Wed Mar 24 20:18:02 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03997; Wed, 24 Mar 93 20:18:02 -0500
Received: from kithrup.com (via garth.kithrup.com) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11652; Wed, 24 Mar 93 20:17:42 -0500
From: "Scott E. Preece" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Work on a uniform API for GUI programming
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2028
Date: 24 Mar 1993 12:50:31 -0800
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)

         Towards a Uniform API for GUI Programming

Four years ago the IEEE began an effort to produce a
standard GUI API based on X.  After about 30 months of
debate over whether the result should be OPEN LOOK or
OSF/Motif, working group P1201.1 changed course, its new
mission to write a standard for a multi-GUI API, an API that
would be implementable on top of a wide range of GUI bases.
The API must be independent of the look and feel of the
delivered interface, yet must support a wide range of
interface functionality.

P1201.1 has gotten technical input from the authors of a
wide range of multi-GUI toolkits and UIMS systems.  The
group has focused its work on developing a programming
language independent model of GUI programming, on which
language specific bindings will be based.  The model
abstracts core elements of the computational model of
several existing multi-GUI toolkits, including XVT, Galaxy,
and THINGS, expressed in an object-based computational model
similar to the programming style of the Xview toolkit.
Interface components are modeled by objects manipulated by
simple object management services (create, destroy, get-
attribute, set-attribute).  The user interface is event-
driven; events are directed to event handlers associated
with each object.

P1201.1 has recently released Draft 7 of its document in
progress.  This draft is the first to present the bones of
the entire model (though some areas have only a little flesh
covering the bones).  At the next IEEE POSIX meeting (19-23
April in Irvine, CA) the group will review the entire
document and work on the details of several key areas and
will also begin serious consideration of the C language
binding.

At this point the group is looking for an expanded core of
interested parties to validate our model and to contribute
to the completion of the standard.  IEEE standards are
supposed to represent a consensus of opinion of a reasonable
slice of the industry; the current working group is diverse,
but small.  We invite the participation of new members; this
meeting would be an especially useful time to join in, as we
will be reviewing the whole document to figure out writing
assignments for completing the language-independent
specification and will be making decisions about the form of
the C API.

We would especially appreciate participation of vendors,
implementors, and users of multi-GUI toolkits, who could
apply their experience to identifying problems or gaps in
our model.

The meeting is 19-23 April 1993 and will be held at the
Irvine Marriott Hotel, in Irvine, CA.  The room rate for
this meeting is $88, single occupancy, if reserved before 26
March (the hotel telephone number is 714-553-0100, specify
the IEEE P1003 meeting).

Although IEEE TCOS meetings are open to all, they are not
free.  The IEEE charges $200 ($230 with four days lunches
included) to attend TCOS meetings.  To get a registration
form, call Brenda Williams at the IEEE Computer Society
(telephone [phone]); she can also provide forms for
subscribing to the mailing service that distributes work
group documents.

I am the Chair of P1201.1.  I would be happy to try to
answer questions about the meetings and to provide copies of
the current draft to those who plan to participate or who
would like to review it and comment electronically.

If you do decide to come to the meeting, please let me know
(preferably by e-mail), so I can track copying and space
requirements.

           Scott Preece
           Motorola Computer Group
           1101 E. University Avenue,
           Urbana, IL   61801

           Internet e-mail:  [e-mail]
           Telephone:        [phone]
           Fax:              217-384-8550


The remainder of this posting is a low-resolution overview
of our computational model.

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

    The P1201.1 Uniform API for GUI Programming

The Uniform API (UAPI) defines a set of services for defining
an application's user interface.  An interface programmed to
the UAPI sufficiently abstract that it can be mapped into any
of a wide range of native window systems.

The UAPI remains abstract by limiting the application's
ability to specify low-level visual details and by allowing
the application to use opaque representations of primitives
obtained, by the implementation, from the native window
system.

This model defers many decisions about placement, visual
representation, and other aspects of the user interface to
the implementation, which must support the UAPI primitives
in a way appropriate to the native window system.  In
principle, the application uses the UAPI primitives to say
what interactions are possible between the user and the
application, without saying very much about how those
interactions are implemented or what they look like to the
user.

Application Model > The UAPI presents an event-driven model
of interaction between the application code and the user
interface.

The UAPI toolkit reacts to user actions by calling
application-provided event handler routines corresponding to
the individual actions each visual object supports.  Each
user action represented in the UAPI model has a
corresponding event.

When the application instantiates a window or control, it
can provide handlers for any events that object supports.

The UAPI implementation provides an event loop, to which the
application hands control after constructing the needed
objects and handlers and setting up any required initial
state.  The event loop waits for user actions (or
notifications from time or data driven application
components) and dispatches them to the appropriate event
handlers.

Objects and Attributes > An application defines its interface
in terms of objects that appear on the user's display.  Each
object belongs to an object class that defines what the
behavior of the object is and what internal state it
contains.

Most interaction between objects in the UAPI or between the
application and the objects defining its user interface
occurs through the manipulation of attributes of the object.
All objects of a given class contain the same attributes.
The toolkit provides operations to get or set the value of
each attribute.

     Some attributes represent the object's stored data;
     setting such an attribute determines the value which
     will be retrieved by subsequently getting the value of
     the same attribute.

     Some attributes represent structural information about
     the object, provided by the toolkit; setting the value
     of such an attribute may not be allowed or may have
     side effects beyond changing the value.

     Some attributes are handles through which the
     application can determine the behavior of the object;
     setting such an attribute has side effects which may
     not be directly reflected in the value retrieved by
     getting the value of the attribute.

An enclosure object corresponds to an screen area displayed
to the user in which the application may place other visual
objects.

A control is an object corresponding to a visual element
with which the user may interact.

Non-visual objects provide supporting functionality for the
application to use, such as lists and timers, but do not
directly correspond to anything visible on screen.

Events >            Each class of object recognizes a
defined set of user actions as indicating events which
should be transmitted to the application.  The application
may associate one or more event handler routines with each
event the object can generate.  When a user action occurs,
the toolkit calls all the event handlers for the
corresponding event, providing each with a piece of data
supplied by the application and with information describing
the exact nature of the event.

The application can also send events to objects and objects
may send events to other objects.

Fonts >             A font is an object designating a
particular style of text display.  The UAPI provides
services for obtaining a native font object by attribute
matching or by user interaction.  A UAPI implementation is
required to provide font objects with certain common names,
so that a portable application may request certain common
text style distinctions.

Color >             A color is an object designating a
particular style of visual presentation of an area of a
screen.  The UAPI provides services for obtaining a native
color object by attribute matching or by user interaction.
A UAPI implementation is required to provide color objects
with certain common names, so that a portable application
may request certain common visual distinctions.

Help System >       The UAPI will include interfaces for
registering and providing help services; this area is still
under discussion.  The goal is to support delivery using (a)
a native help system, (b) an enterprise help system, or (c)
a toolkit-provided help system.

Resources >         Resources are object definitions defined
and stored external to the application and used to provide
attribute values when objects are instantiated.

A UAPI toolkit must provide a tool which reads resource
definitions in a standard format and sets the stored
resources for an application appropriately.

Selections >        A selection is a named piece of data
made available to the application.  A selection may be made
available by the application or by the UAPI implementation;
the toolkit may provide a selection either as a result of an
interaction with the user designating a value as a selection
or as a result of external events, including actions of
other applications.

An implementation provides one or more selection lists, each
containing one or more named selections, each of which is
available in one or more named formats.

Selections also provide a protocol for exchanging data
dynamically, using a sequence of events passed back and
forth between the provider of the selection and the
application.  This dynamic exchange also provides drag-and-
drop capabilities.

Volume-Number: Volume 31, Number 27

From [e-mail]  Fri Mar 26 16:03:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07752; Fri, 26 Mar 93 16:03:40 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21378; Fri, 26 Mar 93 16:03:16 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Algorists, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2029
Date: 26 Mar 1993 12:54:04 -0800
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey Kegler)

In article <[e-mail]> [e-mail] (Dave Cline) writes:
>In article <[e-mail]>,
>             [e-mail] (Jeffrey Kegler) writes:
>> First off, let me point out, that since we are
>> discussing standards, not physical machines, so the matters under
>> discussion are all theoretical models.
>
>Standards contain limits making them finite.  For example, input
>and output arguments in POSIX.1 are defined in terms of their
>ANSI C realizations (2.9.1) and are clearly finite (e.g. INT_MAX,
>sizeof(char *), etc.).

The readership of comp.std.unix should be able to spot the above
reading of the standard as wrong with no trouble.  As a reading of ANSI
X3.159-1989, section 2.2.4.2.1 shows, INT_MAX is a *minimum* -- the
standard gives a magnitude they must be at least as large as, but
implementors may define their magnitudes larger.  sizeof(char *) is
implementation defined, pure and simple (3.3.3.4, 3.3.4, F.3.7).

But suppose it were right.  Is a memory which can consist of an
infinite number of finite words, infinite in extent, or finite?
Mathematics and intuition agree here, that an infinite number of 32 bit
words contains an infinite number of bits.

With the standards and the math, Dave knows the vocabulary, but just
randomly jumbles it.  It looks convincing as long as you know nothing
about what's being discussed.  Dave should consider going into
management.

>Proofs of the halting problem and undecidabilty all rely on the
>fundamental assumption that the state space of the computation model
>is infinite.  Changing from "infinite" to "very large" invalidates
>the proofs.  Our current standards and the machines that implement
>them are finite.  One cannot use Theory of Computation conclusions
>about the halting problem or undecidability if the premises are not
>satisfied.  Jeffrey's appeal to Turing complexity is unjustified.

Herbert S. Wilf, _Algorithms and Complexity_:  "We are going to talk
about a Turing machine.  It is an idealized computer, and its purpose
is to standardize ideas of computability and time of computation by
referring all problems to the one standard machine. ... The beauty of
the Turing machine is that it is at once a strong enough concept that
it can in principle perform any calculation that any other finite-state
machine can do, while at the same time it is logically clean and simple
enough to be useful for proving theorems about complexity.  The
microcomputer on your desktop might have been chosen as the standard
against which polynomial-time computability is measured."

Incidentally, for someone desiring a good introduction to Theory of
Computation, which has the virtue of focusing on essentials, avoiding
much of the wearying detail that afflicts most such texts, I recommend
Wilf.

Speaking of wearying detail, the moderator is losing patience with this
thread, and I cannot blame him.  This will be my last post in reply to
Cline.  This will allow him to have the last word, or as many such as
the moderator cares to allow.  I can pretty much guarantee I won't even
reply to new points raised, however outrageous -- I don't plan to read
any more of Dave's posts.

I do plan to follow the rest of the discussion, and where I read
arguments cogent enough to demand explication, extension or revision of
my statements, I hope for the indulgence of the moderator.

--
Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail]
137 E Fremont AVE #122, Sunnyvale CA 94087

[ Unless further messages have a more direct relevance to "unix standards,"
  I will not post them.  I think the subject of testing is extremely
  important, both to standards and software in general, but this is
  no longer pertaining to the topic at hand.  Please feel free to yell at me if
  you disagree -- mod ]

Volume-Number: Volume 31, Number 28

From [e-mail]  Sat Mar 27 17:43:26 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07108; Sat, 27 Mar 93 17:43:26 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11638; Sat, 27 Mar 93 17:43:23 -0500
Xref: kithrup.com comp.std.unix:13 comp.sys.sun.apps:1 comp.unix.sys5.r4:1 comp.unix.solaris:1
From: [e-mail]
Newsgroups: comp.std.unix,comp.sys.sun.apps,comp.unix.sys5.r4,comp.unix.solaris
Subject: Defining _POSIX_SOURCE on Solaris2.1 makes gdb-4.8 not compile
Followup-To: comp.unix.solaris
Organization: The Wollongong Group, Inc., Palo Alto, CA
Sender: [e-mail]
Distribution: inet
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Mar 1993 13:31:06 -0800
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("David Herron")

Greetings!

I am compiling up the GNU tools for our Solaris 2.1 system (to get my
feet wet on there y'see).  Most have been going together well enough
but gdb just won't go.  This is because of silliness in the include
files supplied by Sun.

In bfd/elf.c is #include <sys/procfs.h>.  The following inconsistencies are
there:

sys/procfs.h contains uses of:

    sigset_t
    u_long, u_char, u_short and u_int
    siginfo_t
    struct sigaltstack

sys/types.h

    defines u_long &c only when !defined(_POSIX_SOURCE)

sys/signal.h

    defines sigset_t when defined(_POSIX_SOURCE)
    defines struct sigaltstack when !defined(_POSIX_SOURCE)

sys/siginfo.h

    defines siginfo_t when !defined(_POSIX_SOURCE)

So there is no way a file containing sys/procfs.h can be defined.

My workaround is to copy sys/signal.h, sys/siginfo.h and sys/procfs.h
to /opt/gnu/lib/gcc-lib/.../include/sys and hack away.

This solution is a rude workaround though.  It makes some non-POSIX
symbols be visible when POSIX_SOURCE is defined.  HOWEVER.. I don't see
how you're supposed to get work accomplished when POSIX_SOURCE is not
defined since that is the only way to get many interesting things only defined!
And then to have any non-POSIX symbol be not visible when it is defined
just makes things downright hard!

David Herron <[e-mail]> (work) <[e-mail]> (home)

[ Note crossposting, and followup -- mod ]

Volume-Number: Volume 31, Number 29

From [e-mail]  Tue Mar 30 18:41:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22560; Tue, 30 Mar 93 18:41:15 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18826; Tue, 30 Mar 93 18:40:40 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 30 Mar 1993 15:33:30 -0800
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Cline)

[ A surprise!  An article that actually mentions a standard or two! -- mod ]

>In article <[e-mail]>
>             [e-mail] (Jeffrey Kegler) writes:

Note to Jeffrey: IMO, your repeated ad hominem attacks are
unprofessional.

[ And no more will be tolerated by me.  I will shamelessy use my
  editorial ability to remove them, if necessary.  Anything Dave
  and Jeffrey have to say about each other they can say in private
  from now on.  Both parties, and third parties, have expressed
  unhappiness at the way the discussion has gone, and I apologise
  heartily for that.  My only excuse is that I have been replacing
  my computer system, and was somewhat distracted.  I will try not
  to let it happen again -- mod ]

>The readership of comp.std.unix should be able to spot the above
>reading of the standard as wrong with no trouble.  As a reading of ANSI
>X3.159-1989, section 2.2.4.2.1 shows, INT_MAX is a *minimum* -- the
>standard gives a magnitude they must be at least as large as, but
>implementors may define their magnitudes larger.

Sure, an *implementation* is free to extend the range of
integers beyond the minimum guaranteed INT_MAX value.  That's a
given.  However, the context of this discussion is test method
standards and test suites for various Unix standards (not just
the misapplication of Turing machine models).  The rules are
obviously a bit different for test suites, (or at least it seems
to me that it should have been obvious).

A test method implementation that blindly stores a value greater
than the minimum guaranteed value of INT_MAX into an int is
incorrect, or at least not strictly conforming according to the
ANSI C and POSIX.1 rules.  A standard conforming C compilation
system could (quite properly) reject such a test implementation
if the implementation supported only a 16 bit ints.  If the
conformance test suite isn't portable, it isn't a valid test of
system conformance.  So while INT_MAX may not constrain an
implementation, it does constrain a test suite.

>sizeof(char *) is
>implementation defined, pure and simple (3.3.3.4, 3.3.4, F.3.7).

Agreed, sizeof(char *) is implementation defined.  But it must be
finite.

The reasoning is as follows: a conforming compilation system
must accept all strictly conforming programs (X3.159-1989
section 1.7).  A strictly conforming program that computes (at
runtime) the usual idiom for the number of elements in an array
of character pointers (sizeof(x)/sizeof(x[0])) would fail if
sizeof(char *) was unbounded because +infinity/+infinity makes
no arithmetic sense.  OK?

>But suppose it were right.  Is a memory which can consist of an
>infinite number of finite words, infinite in extent, or finite?
>Mathematics and intuition agree here, that an infinite number of 32 bit
>words contains an infinite number of bits.

As noted above, this model violates ANSI C because it would lead
to an infinite sizeof(char *) which breaks at least one strictly
conforming program (all bytes must be addressible).

The reverse, a model with a finite number of containers, each
of which can store an arbitrarily large integer, also violates
ANSI C. The reasoning goes as follows: sizeof(x) gives the
number of bytes in x and must be finite (see above).  It is
required that each byte of an object be uniquely addressable
(1.6 def'n of byte).  Of necessity, one must then define the
byte as the arbitrarily sized container.  The definition of byte
in ANSI C (1.6) refers to a low order bit and a high order bit.
Hence, a byte is a bounded and finite quantity.  This leads to a
contradiction.

As further evidence of the ANSI C requirement for finite
containers, I could cite the definition of integral types in
3.1.2.5, the rules for integral promotion, the rationale, etc.
It's really moot.  The point is that Jeffrey's Turing model
doesn't match the real world of machines and standards.

Bottom line
-----------

The ANSI C memory model requires a finite number of finite-sized
containers.  By extension, the POSIX.1 memory model has the same
requirements.  Turing undecidability results require an infinite
state space.  There is no undecidability in a finite state space.
Proofs to the contrary will be welcomed in comp.theory.

This corresponds quite closely to everyone's (well, almost
everyone's) intuition.  The real world does not accept Jeffrey's
undecidability argument.  If he were correct, test suites for
most standards would be compromised by these undecidability
issues.  In practice, they don't arise.

Here's a challenge to Jeffrey: give an example from POSIX.1
where his Turing model undecidability would invalidate an
otherwise legitimate assertion.

--
Dave Cline                                  [e-mail]
Spring Valley Software

[ Note the reference to comp.theory.  Note the previous comments by
  me, your moderator.  Note that anyone who tries my patience will
  not get any truffles the next time I bring them to UseNIX 8-).
  Above all, please note that this is not alt.flame, and my apologies
  for not being up to snuff recently -- mod ]

Volume-Number: Volume 31, Number 30

From [e-mail]  Mon Apr  5 18:43:20 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12178; Mon, 5 Apr 93 18:43:20 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01502; Mon, 5 Apr 93 18:43:19 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Electronic Balloting
Organization: Colorado SuperNet, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 5 Apr 1993 15:37:26 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey Haemer)

              Electronic Balloting Software

       What if you could FTP POSIX draft standards and ballot on
       them from the comfort of    your own keyboard?  No more messy
       stamps or ink-stained fingers!  No need to wait on the Pos-
       tal "Service" for the latest drafts!

       We see a    future in which    draft standards    will be    available
       for anonymous FTP, and balloting    can be done by email.  For
       a variety of reasons -- some sensible, some merely histori-
       cal -- achieving    either of these    advances requires overcom-
       ing both    political and technical    barriers.  We'd    like to
       remove the technical barriers.  Andrew Hume has already
       demonstrated a prototype    solution for electronic    draft dis-
       tribution.  We'd    like to    see a prototype    for electronic bal-
       loting, and we'd    like your help to make this happen.

       It's envisioned that any    electronic balloting procedure will
       need (a)    authentication at least    as good    as Snail Mail pro-
       vides and (b) vote-counting software to make it as painless
       as possible.

       Quick-and-dirty authentication can be as    simple as (1) mail
       the ballot-request software, which then (2) generates an
       encryption key and (3) sends it,    via postal mail    (wouldn't
       want them to feel _too_ left out!) to the requester, who
       then (4)    uses the out-of-band key to encrypt the    ballot,
       which is    then (5) decrypted by the balloting software and
       (6) counted appropriately -- or at least    that's the plan.

       What's wrong with the plan?  How    can it be made better?    How
       interesting can the vote-counting software get?    Should it
       be written in perl?

       Please contribute your thoughts,    code, etc., and    help standards
       balloting step into the 1990s.


       - Jeffrey S. Haemer, USENIX Standards Liaison   <[e-mail]>
       - Pat Wilson, SAGE Board    Member <[e-mail]>


Volume-Number: Volume 31, Number 31

From [e-mail]  Tue Apr  6 13:39:44 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22615; Tue, 6 Apr 93 13:39:44 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04073; Tue, 6 Apr 93 13:39:44 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Request for Technology
Organization: X/Open Company Ltd
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 6 Apr 1993 10:31:05 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (James Andrews)

X/Open is developing a test suite for XPG4 Commands and
Utilities.  The test suite (currently known as XCUTS) will
be capable of testing for conformance to POSIX.2 (IEEE Std 1003.2-1992).
It will also satisfy the requirements specified by NIST for use as a
POSIX.2 FIPS certification test suite, and the requirements
of the EC CTS5 proposal to establish ISO9945-2 test services
within Europe.

X/Open wishes to minimize development timescales and to ensure openness
of the process for development of the test suite.
X/Open is therefore seeking donation of technology or development
resources but is also prepared to consider funding some
commercial development. Thus the development work has been
provisionally broken into packages some of which may be fulfilled
by free donation from various sources. Others may be met by
commercial development under our open tender process.

In a previous RFQ, X/Open selected BSI Quality assurance and Mindcraft
jointly to serve as the test suite integrator.  Their tasks are to
ensure the uniformity of style and quality of the code from the package
suppliers, to integrate them into a single seamless test
suite, to act as technical advisors and to provide technical
project management resources.

X/Open has received a number of offers of free technology
from its shareholders. X/Open also has had an 'in principle' offer from an
outside organisation to be a development partner providing
both IPR and resources free of commercial constraint.

X/Open wishes to know if other companies or organizations are
interested in participating in the development of XCUTS, or
have test suite technology (utilities, implementation
tools) which they may be prepared to make available under any terms
whatsoever X/Open.

BSI, under contract to X/Open, will put out a Request For Quotation
for development of those packages that will go to open tender.
Before that occurs, X/Open would like to know what technologies
we should be considering.

Note that BSI and Mindcraft are precluded from acting as package
suppliers under the terms of their integration contract.

If you are interested in providing technology of the sort
described above for use in XCUTS, please mail me at the attached
Address of your interest within one week. Follow this up
by letting me know what you are suggesting within two weeks.

If you are interested in Tendering for the packages but do not have
specific technology to be used in XCUTS, let us know of your interest
to ensure that you will receive a package when the RFP is
distributed.  There may be a modest cost associated with
participating in the RFP to cover the costs of the materials
distributed; we estimate that it would be about $150.  It is
assumed that you already have a copy of the XPG4 Commands
and Utilities specification.  Your response now can directly
influence the project and the shape of any commercial RFP's.

There are certain technical constraints that govern the
architecture of XCUTS.  These arise both from X/Open
requirements and from NIST and European Commission CTS5
requirements.  While we cannot give all those constraints in
this document, here are some crucial points:

  1.  The Test Environment Toolkit (TET) must be used as the
      common test harness for all test development.

  2.  The API to be used shall be the TET API plus
      interfaces defined in the Style and Quality Assurance
      Guide (to be provided by the integrators).  NOTE: If
      you want to suggest an API, do so; you should be aware
      that anything beyond TET will require the approval of
      the X/Open Test Development Group.

  3.  Tests must conform to the requirements of POSIX.3
      (IEEE Std 1003.2-1991).

  4.  Tests for POSIX.2 must use the assertions in the most
      current draft of POSIX.3.2, and must track changes in
      subsequent drafts through the test development cycle.
      (This will likely encompass a single new draft.)
      Package suppliers will be required to review the draft
      POSIX.3.2 assertions for correctness and to submit
      corrections to both the POSIX.3.2 committee and the
      integrators.  Test assertions must be developed for
      those portions of XPG4 Commands and Utilities outside
      the scope of POSIX.2.  The writing and review of these
      assertions will be part of the test suite development
      effort.

  5.  Tests must be written in the POSIX.2 Shell language
      whenever possible.  When C is required, Standard C
      shall be used.

  6.  Tests must be so structured that no assertion test
      depends on the execution or results of any prior test.

DO NOT SUBMIT ANY CONFIDENTIAL MATERIAL IN YOUR RESPONSE.
We will assume that all responses can be exchanged freely
among the organizations evaluating your response.

Regards

--
James Andrews                                         X/Open Company Limited
Conformance Quality Mgr                             Apex Plaza, Forbury Road
EMail: [e-mail]                       Reading, England, RG1 1AX
Tel: +(44) (0)734 508311                            FAX: +(44) (0)734 500110

Volume-Number: Volume 31, Number 32

From [e-mail]  Fri Apr  9 17:05:04 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04437; Fri, 9 Apr 93 17:05:04 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24603; Fri, 9 Apr 93 17:04:59 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: Electronic Balloting
Organization: Data General Corporation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Apr 1993 13:59:51 -0700
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]>, [e-mail] (Jeffrey Haemer) writes:
>               Electronic Balloting Software

Great idea!

>Quick-and-dirty authentication can be as simple as (1) mail
>the ballot-request software, which then (2) generates an
>encryption key and (3) sends it, via postal mail (wouldn't
>want them to feel _too_ left out!) to the requester, who
>then (4) uses the out-of-band key to encrypt the ballot,
>which is then (5) decrypted by the balloting software and
>(6) counted appropriately -- or at least that's the plan.

The authentication can be even quicker.  There is really no need to
encrypt/decrypt the ballot.  Step (3) could send several out-of-band
passwords; One for yes, one for no, one for abstain, and so on.  The
ballotor can then send back his vote & password along with the clear
text of any objections/comments.

The passwords would prevent someone from changing a YES vote to a NO
vote.  Encryption of comments, objects and the voters name do not
add any real security.  If we are concerned that an attacker might
change the text of a comment or objection, we need to also make sure
that he cannot change the draft I am getting via FTP or E-Mail.

Personally, I am willing to trust the internet with the plain text
of the draft and the comments.  When using plain text there is less
to go wrong and correction is easier.

>What's wrong with the plan?  How can it be made better? How
>interesting can the vote-counting software get? Should it
>be written in perl?

How about restricting the vote-counting software to be POSIX.1 and
POSIX.2 conforming?  Let's use some of the portability and verification
tools we are already building.

--------------------------------------------------------------------
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 31, Number 33

From [e-mail]  Sat Apr 10 02:02:01 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00966; Sat, 10 Apr 93 02:02:01 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29496; Sat, 10 Apr 93 02:01:54 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Posix.9 report
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Apr 1993 22:59:32 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Nick Stoughton)

As the new Usenix standards editor (watch this space for more on this),
I should get this comment on January's Posix.9 meeting published before
we get to the April one...

        Report on POSIX.9: FORTRAN Bindings

Michael J. Hannah <[e-mail]>, the chair of the POSIX.9
committee, gives his views on the January meeting of the POSIX.9,
and the new POSIX.19 committees.

The POSIX.9 (Fortran bindings) group, though sparsely attended, did meet in
January and made progress towards their next project.  While other IEEE
standards have been drafted by three people, this is uncommon for POSIX.  A
committee of such small size implies a very significant reliance on the
ultimate balloting group.  There is nothing wrong with a small group doing
the draft, but before such a draft becomes a standard it must be
reviewed and examined by a much larger, representative, balloting group.
While there may be nothing improper or illegal with this approach, I
would certainly like to see more participation in our meetings.

IEEE Std 1003.9-1992 is approved and was available for purchase at this
meeting.  This standard completely defines how to access ALL
functionality of ISO/IEC 9945-1:1990 from FORTRAN 77, as well as
defining a generalized way to access any operating system structure and
defining byte-stream I/O for FORTRAN 77.  Since FORTRAN 77 is
essentially a subset of the new Fortran 90 standard, IEEE Std
1003.9-1992 is completely usable in a Fortran 90 environment.  Like any
standards committee that just completed a standard, the committee
discussed how to convince vendors to implement this standard, and how
to convince users to demand this standard from the vendors.

Actual work was begun on draft 0 of the next project for this
committee, P1003.19, which is a binding between the Language
Independent Specification (LIS) of 1003.1 and the new Fortran 90
language standard.  This Project Authorization Request (PAR) was
approved by the IEEE standards board in Sept 1992, though approved over
a year ago by the SEC.  Part of the delay was ensuring complete liaison
with X3J3, the Fortran Language committee.  At their August 1992
meeting, the X3J3 approved an official resolution endorsing the scope
of the P1003.19 PAR and agreed to active liaison with the 1003.9
committee.  This is significant since the P1003.19 PAR includes in its
scope the ability to define extensions to the base language standard of
Fortran 90.  One of the major unresolved objections in balloting IEEE
Std 1003.9- 1992 was that many of the functions could have been defined
as simple extensions to the base standard syntax.  For example, mode
bits could be included as an extension to the Fortran OPEN statement,
etc.  Such an approach is planned for the P1003.19 work.

The committee began by discussing the overall approach to the new
work.  In addition to examining the new language features in Fortran
90, the committee discussed how this new binding should relate to the
1003.1 LIS and its companion 1003.1 C binding.  While this POSIX
standards body is focused on portability of applications, as an end
user I am particularly concerned about portability for application
writers.  Whether to point to the LIS or point to the ``historical
practice'' of C is a contentious issue.  For example, the LIS describes
a procedure called change_file_mode, while the traditional C
function is called chmod.  In IEEE Std 1003.9-1992, because any
function/subroutine name in FORTRAN 77 was exposed to the loader, and
since the IEEE Std 1003.9-1992 routine to change file mode had to be
slightly different than chmod, we had to give it a distinct name,
PXFCHMOD.  Because of the new features of Fortran 90, module
names used by an application are not necessarily exposed to the
loader.  Thus we COULD now call the Fortran 90 routine chmod
without fear of conflict with a different C library routine of the same
name.  Using chmod as the name is intuitive to any programmer
coming from the C world, but is not intuitive to a strictly Fortran
programmer.  While the argument in this example may be stronger for
chmod since there is also a 1003.2 command by that same name,
such an argument does not apply to all 1003.1 functions.  If you really
believe in the concept of the LIS, and especially if the new C binding
is ``thin,'' then a name that is the same as the LIS
change_file_mode might be more appropriate.  A Fortran 90
bindings reader should need at most the 1003.19 binding and the 1003.1
LIS.  However, many LIS names are more than 31 characters, so some
mapping may be required, or an extension to Fortran 90 to recognize
uniqueness in names longer than 31 characters.  This seems to be
something like a religious issue, where parties on each side are
CERTAIN that their position is correct, and the only intelligent
position.  The current committee default is to use the long LIS names,
NOT the familiar C names, but this may change.

One item of interest is that new constructs in Fortran 90 seem to
permit the binding to be completely specified as Fortran 90 code
fragments.  Whether the IEEE and ISO document structures could be
accommodated by this is unclear.  For an implementation, you would like
to give an electronic copy of the binding (code fragments) to the
implementor so they could simply add the rest of the code necessary on
their implementation.  Since the code fragments completely define the
application interfaces, this would be a boon for everybody.  However,
such a scheme also raises the question among the lawyer folk as to what
this would mean with regard to the IEEE copyright of the binding.

Finally, the committee was actively involved in the hot debate
concerning whether the POSIX Executive Committee should rescind its
mandatory requirement for base POSIX standards to be developed as
Language Independent Specifications (LIS).  As a language binding
committee we are viewed as the direct beneficiaries of the work to
produce an LIS. The members of the bindings committee of both the
1003.4-Ada and 1003.9-Fortran have strong opinions on this issue.

The 1003.9 committee is scheduled to meet the first three days of the April
POSIX meeting.

Volume-Number: Volume 31, Number 34

From [e-mail]  Thu Apr 15 17:04:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05954; Thu, 15 Apr 93 17:04:37 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05198; Thu, 15 Apr 93 17:04:03 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: POSIX status
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 1993 11:06:50 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

                                                        PASC SEC SD11







                             POSIX Status

                              April 1993


         Project                              Estimated  Probable
                            Ballot Type                            Est Size
         Number                              Ballot Date Draft No.
  __________________________________________________________________________

  P1003.0               Mock/WG15 R&C *      Nov '91        D13    ~250 Pgs
  (POSIX Guide)         1st Ballot *         Aug '92        D15     287 Pgs
                        SC22 R&C *           2Q93           D16     287 Pgs
                        CD/PDAM              3Q93            D?    ~287 Pgs
  __________________________________________________________________________
  P1003.1a              1st Ballot/SC22 R&C -3Q93           D7+    ~100 Pgs
  (System Interface     CD/PDAM              93+             D?    ~100 Pgs
  Extensions)

  Lang. Indpt Spec      Mock Ballot          Fall '91              ~400 Pgs
                        WG15 R&C             1Q92                  ~400 Pgs
                        1st Ballot           July '92        D3    ~400 Pgs
                        SC22 R&C             4Q92            D3    ~400 Pgs
                        2nd Ballot           3Q93            D4    ~400 Pgs
                        CD/PDAM              3Q93            D5    ~400 Pgs
                        Final/DIS Ballot     4Q93            D6    ~400 Pgs
  __________________________________________________________________________
  P1003.2/2a (Shell &   APPROVED             9/92
  Tools/User Port Ext)  IS Ballot            4Q92

  P1003.2b              1st Ballot           3Q93            D?     TBD Pgs
  (ISO Revision)
  __________________________________________________________________________
  P1003.3               APPROVED             3/91
  (Test Methods)        CD/PDAM              2Q92

  P1003.3.1             APPROVED             12/92

  P1003.3.2             1st Ballot/SC22 R&C  4Q92            D8    ~500 Pgs
  __________________________________________________________________________
  P1003.4               Recirc               Apr '92        D12    ~320 Pgs
  (Realtime)            Recirc               Jun '92       D12.01  ~320 Pgs
                        Recirc               Oct '92        D13    ~320 Pgs
                        Recirc               Apr '93        D14    ~320 Pgs
                        CD/PDAM              1Q91           D10    ~400 Pgs
                        Final                Jun '93        D14    ~320 Pgs

  P1003.4a              1st Recirc           1Q92            D6    ~200 Pgs
                        2nd Recirc           Apr '92         D7    ~200 Pgs
                        3rd Recirc           May '93         D8    ~200 Pgs
                        CD/PDAM              4Q93

  P1003.4b              WG15 R&C             4Q92            D?       TBD
                        1st Ballot/SC22 R&C  3Q93           D6?       TBD

  P1003.4c (L. I.)      1st Ballot/SC22 R&C  3Q93           TBD       TBD
  __________________________________________________________________________
  P1003.5               APPROVED             6/92
  (Ada)                 CD/PDAM              93+
  __________________________________________________________________________
  P1003.6               1st Ballot/SC22 R&C  Oct '91        D12     387 Pgs
  (Security)            1st Recirc           Dec '92        D13    ~400 Pgs
                        CD/PDAM              3Q93           D15    ~400 Pgs
  __________________________________________________________________________
  P1003.7.1             Mock                 2Q92            D5
  (Print Admin)         WG15 R&C S&F=        May '92
                        1st Ballot           Jun '93         D7    ~350 Pgs
                        WG15 R&C             2Q93
                        SC22 R&C             4Q93
                        CD/PDAM              4Q93

  P1003.7.2             WG15 R&C S&F=        May '92
  (Software Admin)      Mock                 Mar '93         D8    ~300 Pgs
                        WG15 R&C             2Q93
                        SC22 R&C             4Q93
                        4D/PDAM              1Q93
  __________________________________________________________________________
  P1003.8               Mock                 3Q91            D4     ~60 Pgs
  (TFA)                 WG15 R&C             1Q92            D5     ~60 Pgs
                        1st Ballot           May '92         D6     108 Pgs
                        1st Recirc           2Q93            D7    ~100 Pgs
                        SC22 R&C             2Q93            D7    ~100 Pgs
                        CD/PDAM              3Q92            D?    ~100 Pgs
  __________________________________________________________________________
  P1003.9 (Fortran)     APPROVED             6/92
  __________________________________________________________________________
  P1003.10              1st Ballot/SC22 R&C  Nov '92        D11     ~75 Pgs
  (Supercomputing AEP)
  __________________________________________________________________________
  P1003.11              Mock                 1Q92            D6     ~75 Pgs
  (Trans Proc AEP)      1st Ballot/WG15 R&C  3Q92            D7     ~50 Pgs
                        Survey               12/92
  __________________________________________________________________________
  P1003.12              Mock/WG15 R&C        4Q92            D2    ~300 Pgs
  (Protocol Indpt.)     1st Ballot/SC22 R&C  3Q93            D4    ~400 Pgs
                        CD/PDAM              4Q93            D?
  __________________________________________________________________________
  P1003.13              1st Ballot           May '92         D5     ~80 Pgs
  (Realtime AEP)        WG15 R&C             3Q93            D7     ~80 Pgs
                        1st Recirc           3Q93            D6     ~80 Pgs
  __________________________________________________________________________
  P1003.14              Mock/WG15 R&C        3Q92            D5     ~50 Pgs
  (Multi Proc AEP)      1st Ballot/SC22 R&C  3Q93            D?
  __________________________________________________________________________
  P1003.15              1st Ballot           Dec '92        D12    ~175 Pgs
  (Batch)               SC22 R&C             1Q93           D12    ~175 Pgs
                        CD/PDAM              3Q93            D?
  __________________________________________________________________________
  P1003.16              Mock Ballot          Fall '91        D2
  (C Binding)           WG15 R&C             1Q92            D2
  (Synchronized         1st Ballot           July '92        D3    ~200 Pgs
   with P1003.1 LI)     SC22 R&C             4Q92            D3    ~200 Pgs
                        1st Recirc           3Q93            D4    ~200 Pgs
                        CD/PDAM              3Q93            D5    ~200 Pgs
                        Final/DIS Ballot     4Q93            D6    ~200 Pgs
  __________________________________________________________________________
  P1003.17              APPROVED             3/93
  (Directory/NS)        ISO Fast Track       2Q93
    (1224.2, 1326.2)
    (1327.2, 1328.2)
  __________________________________________________________________________
  P1003.18              Mock                 Oct '91         D5
  (POSIX Profile)       2nd Mock             May '92         D6    ~100 Pgs
                        WG15 R&C             1Q93
                        1st Ballot           4Q93           D7+    ~100 Pgs
  __________________________________________________________________________
  P1003.19              Mock
  (Fortran 90)
  __________________________________________________________________________
  P1003.20              Mock                 Dec '92
  (Ada Realtime)        1st Ballot           3Q93
  __________________________________________________________________________
  P1201 (User I/F)
  P1201.1
  (Interfaces)
  P1201.2               1st Ballot/SC22 R&C  3Q92            D1     183 Pgs
  (Drivability)         Recirc               2Q93            D2    ~180 Pgs
  __________________________________________________________________________
  P1224 (ASN.1          APPROVED             3/93
  Obj Mgt Spec)         ISO Fast Track       2Q93
    (1224, 1326)
    (1327, 1328)
  P1224.1 (X.400 API)   APPROVED             3/93
    (1224.1, 1326.1)    ISO Fast Track       2Q93
    (1327.1, 1328.1)
  __________________________________________________________________________
  P1237 (RPC)           moved to X3
  __________________________________________________________________________
  P1238 (FTAM)
  P1238.0               Mock/WG15 R&C        Jan '92         D4
  (Support Fncs)        1st Ballot/SC22 R&C  Jun '93         D2
  P1238.1               1st Ballot/SC22 R&C  '93             D?
  FTAM I/F


  ____________

    * According to the PASC Synchronization Plan, the Mock Ballot of
      a draft will indicate the draft is ready to be sent to ISO
      SC22/WG15 for Review and Comment, and the first ballot will
      indicate the draft is ready to be sent to ISO SC22 for Review
      and Comment.

    - 1003.1a will be approximately one meeting behind the LIS to
      start ballot.

    = WG15 R&C S&F indicates review and comment by WG15 of the scope
      and functionality of this proposed standard.




                                                        PASC SEC SD11

 ________________________________________________________________________
 |                    Highlights of POSIX Most Active                   |
 |______________________________________________________________________|
 |  Project  |  Draft |  AT IEEE |  Start of  |  Close of|     Ballot   |
 |           |  Number|   Office |   Ballot   |   Ballot |  Coordinator |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.0   |   D15  |          |    8/3/92  |  8/31/92 |     Lewis    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.1LIS|    D4  |  7/17/93 |   8/17/93  |  9/17/93 |     Rabin    |
 | P1003.16  |    D4  |  7/17/93 |   8/17/93  |  9/17/93 |     Rabin    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.3.2 |    D8  |  11/6/92 |   12/6/92  |    3/93  |    Johnson   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.4   |   D14  |   3/5/93 |    4/5/93  |  4/16/93 |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.4a  |    D8  |  4/14/93 |   5/14/93  |  6/14/93 |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.4c  |    D?  |          |     2Q93   |    2Q93  |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.6   |   D13  |  11/30/92|   12/31/92 |    3/93  |    Ressler   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.7.1 |    D7  |  5/10/93 |   6/10/93  |  7/16/93 |  D'Alessandro|
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.8   |    D6  |    2Q93  |     2Q93   |    2Q93  |     Zions    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.10  |   D11  |  10/16/92|   11/16/92 |  12/16/92|    Sheaffer  |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.11  |  Survey|   12/92  |    12/92   |    1Q93  |      Poon    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.13  |    D6  |          |     3Q93   |    3Q93  |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.15  |   D12  |  11/15/92|   12/15/92 |    3/93  |    Sheaffer  |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.18  |        |    4Q93  |     4Q93   |    4Q93  |              |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.20  |        |    3Q93  |     3Q93   |    3Q93  |              |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1201.2   |    D1  |          |   6/17/92  |  7/17/92 |     Kurys    |
 |           |        |          |            |          |              |
 | P1201.2   |    D2  |          |     2Q93   |    2Q93  |     Kurys    |
 |___________|________|__________|____________|__________|______________|


  For copies of standards or current drafts, call the IEEE Computer
  Society at 202-371-0101.



Volume-Number: Volume 31, Number 35

From [e-mail]  Thu Apr 15 17:04:53 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06042; Thu, 15 Apr 93 17:04:53 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05577; Thu, 15 Apr 93 17:04:52 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Quarterly report
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 1993 11:08:11 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

  ____________________________________________________________________
  PASC SEC SD11



  subject: Balloting Vice-Chair Status          date: April 14, 1993
           Report - 2nd Quarter 1993
                                                from: L. C. Kevra
                                                      908-234-6423
                                                      [e-mail]



  To:  PASC/SEC


  The following is a status report on items of interest to the
  PASC/SEC working groups concerning balloting issues.


  1.  IEEE Balloting Contacts

  As a reminder, Anne O'Neill (Staff Engineer at the IEEE Standards
  Department in Piscataway, NJ) serves as the project manager for the
  IEEE POSIX balloting efforts; she handles all general planning and
  policies for the assorted POSIX working groups ballots.  Anne can
  be reached at 908-562-3809.  Anna Kaczmarek (908 562 3811) is
  responsible for all invitations to ballot.  Carol Buonfiglio (908
  562 3834) handles all other ballot related activities: all ballots
  sent out for the first time, all reballots, and all recirculation
  ballots.


  2.  Current Balloting Group Status

  Congratulations to all those who worked so hard to create and
  complete the 1224, 1224.1 and 1224.2 (1003.17)  IEEE Standards
  (with associated language bindings and test methods); they were
  approved at the March 1993 IEEE Standards Board Meeting!

  As of April 7, the following groups are at some stage of the
  balloting process:

  PASC/SEC -  Ballot resolution.

  P1003.0 -   Ballot resolution.

  P1003.1LIS/.16 -  Ballot resolution.

  P1003.3.2 -  Recirculation ballot closed 3/93; in ballot
              resolution.




                                  -1-







                                                        PASC SEC SD11



  P1003.4 -   Final ballot recirculation closed 4/16/93; projected
              submission to the IEEE Standards Board June 1993.

  P1003.4a -  Ballot recirculation from May 14 to June 14, 1993.

  P1003.6 -   Recirculation ballot closed 3/93; in ballot resolution.

  P1003.7.1 -  First ballot scheduled from June 10 to July 16, 1993.

  P1003.8 -   Ballot resolution.

  P1003.10 -  Ballot resolution.

  P1003.11 -  Survey of next steps for the working group.

  P1003.13 -  Ballot resolution.

  P1003.15 -  Recirculation ballot closed 3/93; in ballot resolution.

  P1201.2 -   Ballot resolution.


  3.  Call for Balloting Groups Formation

  The IEEE office is planning to send out a letter to the PASC
  balloting pool on April 30, 1993 (after the April 1993 POSIX
  meetings) inviting them to joint the balloting group(s) for our
  next round of standards ready to go to ballot.  The invitation will
  close on June 7, 1993 allowing for first ballots to be sent out
  after that date.  As of April 7, 1993, two groups have identified a
  need to form new balloting groups:

     o 1003.20 (Ada Realtime APIs)

     o 1238.0 (FTAM Support Functions)

  As of April 7, the IEEE office plans to keep the balloting fee at
  $50 per group.  If you need to form a balloting group, please
  contact Lorraine Kevra or Anne O'Neill after the Irvine POSIX
  meetings.  Please note: If there are balloting dependencies on
  other document(s), the instructions on how to obtain them must be
  provided by the ballot coordinator to the IEEE office.


  4.  Recirculation Balloting Period

  There has been a change to the balloting procedures as documented
  in the IEEE Standards Operations Manual and IEEE Standards Board
  Bylaws (dated December 1992).  Ballots will close on the deadline
  (given 75% return has been achieved), or when 75% return is
  achieved or 60 days after the published closing date, whichever
  occurs first.  You must receive a 75% response in this new time


                                  -2-







                                                        PASC SEC SD11



  frame, or there is the potential that your document will be at risk
  to continue balloting, especially during its first ballot attempt.


  5.  Overlapping Balloting Windows

  Just a reminder to reserve your balloting window with Lorraine
  Kevra as soon as possible -- it's first come, first serve for
  balloting time periods on the calendar.  Other requests will be
  staggered to give balloters adequate time to comment on drafts, and
  to give the IEEE office an appropriate amount of time to copy and
  distribute ballots.


  6.  Balloting Group Membership

  Following is the latest balloting membership figures:

  _____________________________________________________________________________
 |     Group     |  Total Balloting Membership|  Official Balloting Membership|
 |_______________|____________________________|_______________________________|
 | PASC          |             378            |               335             |
 |_______________|____________________________|_______________________________|
 | P1003.0       |              72            |               68              |
 |_______________|____________________________|_______________________________|
 | P1003.1LIS/.16|             123            |               112             |
 | P1003.1LIS    |              -             |               +9-             |
 |_______________|____________________________|_______________________________|
 | P1003.1a      |              90            |               85              |
 |_______________|____________________________|_______________________________|
 | P1003.3.2     |              47            |               45              |
 |_______________|____________________________|_______________________________|
 | P1003.4       |             268            |               239             |
 | P1003.4a      |             229            |               195             |
 |_______________|____________________________|_______________________________|
 | P1003.6       |             274            |               274             |
 |_______________|____________________________|_______________________________|
 | P1003.7.1     |              53            |               52              |
 |_______________|____________________________|_______________________________|
 | P1003.8       |              93            |               86              |
 |_______________|____________________________|_______________________________|
 | P1003.10      |              54            |               51              |
 |_______________|____________________________|_______________________________|
 | P1003.11      |              53            |               48              |
 |_______________|____________________________|_______________________________|
 | P1003.13      |             100            |               92              |
 |_______________|____________________________|_______________________________|
 | P1003.15      |              51            |               49              |
 |_______________|____________________________|_______________________________|
 | P1003.18      |              77            |               72              |
 |_______________|____________________________|_______________________________|




                                  -3-







                                                        PASC SEC SD11



  7.  Conclusion

  PASC is making good progress in bringing completed documents to the
  IEEE Standards Board and there are numerous parallel groups
  progressing their documents.  PASC has strong advocates on the IEEE
  Standards Board since both Jim Isaak and Lorraine Kevra are members
  of the Board for 1993.  There is the potential for overlapping
  balloting windows, and I will be watching closely to make sure that
  the PASC balloters are not overwhelmed by the number of drafts
  coming their way.

  I welcome you input on this status report and suggestions on topics
  you would like covered in upcoming balloting status reports.



                                   L. C. Kevra



























  ____________

    - In addition to those who are balloting on .1LIS and .16, 9
      additional parties of interest are commenting on 1003.1LIS
      only.





                                  -4-






Volume-Number: Volume 31, Number 36

From [e-mail]  Thu Apr 15 17:05:08 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06102; Thu, 15 Apr 93 17:05:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05643; Thu, 15 Apr 93 17:05:04 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: expr questions
Organization: Kaleida Labs, Inc., Mountain View, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Apr 1993 11:09:34 -0700
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (J.T. Conklin)

I am unable to determine the "proper" behavior of the expr program
from all of the specifications availiable to me (various man pages,
and the X/Open Portability Guides).

All of the man pages contain something like this:

    expr | expr
    Return the first expr if it is neither NULL nor 0, otherwise
    returns    the second expr.

     expr & expr
    Return the first expr if neither expr is NULL or 0, otherwise
    returns 0.

Since expr will coerce a string into an interger in other contexts, I
am wondering if a string like 0000 should be interpreted as zero?  All
of the implementations (that worked at all) I've tried do not.

I've patched the broken versions (386BSD & GNU) to the traditional
behavior, but I'm curious to know if the traditional behavior is
actually incorrect.

--
J.T. Conklin <[e-mail]>    | Your source for floppy distributions
    Winning Strategies, Inc.     |    of the 386BSD OS and binaries
    61 Crestwood Drive #18       |
    Daly City, CA 94015          | Send e-mail for complete product list



Volume-Number: Volume 31, Number 37

From [e-mail]  Fri Apr 16 16:15:48 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05805; Fri, 16 Apr 93 16:15:48 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20400; Fri, 16 Apr 93 16:15:35 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re:  expr questions
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 16 Apr 1993 13:03:54 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

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

[e-mail] (J.T. Conklin) asked:
>Since expr will coerce a string into an interger in other contexts, I
>am wondering if a string like 0000 should be interpreted as zero?  All
>of the implementations (that worked at all) I've tried do not.
>I've patched the broken versions (386BSD & GNU) to the traditional
>behavior, but I'm curious to know if the traditional behavior is
>actually incorrect.

In P1003.2 Draft 11, the entry for expr (4.22.7, page 401) defines "integer"
as "An argument consisting only of an (optional) unary minus followed by
digits."

By this definition, "0000" is an integer.

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

Volume-Number: Volume 31, Number 38

From [e-mail]  Thu Apr 22 19:04:31 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03819; Thu, 22 Apr 93 19:04:31 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29313; Thu, 22 Apr 93 19:04:17 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: Job Control and POSIX
Organization: Motorola Computer Group, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 22 Apr 1993 15:55:15 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

This is in reply to a posting on 25 Feb by [e-mail].
Unfortunately, my system has long since purged that message, and I
have only a hard copy.

The original message said, in effect, that POSIX requires read to
return -1 and set errno to EINTR if it is interrupted by a job control
signal before transferring any data.  This caused the poster's csh job
(which contained a pipeline) to die when suspended.

This issue was discussed today at the POSIX.1 meeting.  While I think
that I have captured the consensus of the group, you should take this
as my personal opinion, and not anything official from the IEEE.  If
you want something official, you'll have to ask the IEEE for an
interpretation request.  (This certainly is not an official Motorola
position, either.)

I think that the failure described here is due to a misunderstanding
of the phrase "interrupted by a signal."  The description of read() does
contain the sentence:

    If a read() is interrupted by a signal before it reads any data, it
    shall return -1 with errno set to [EINTR].

However, see subclause 3.3.1.4, which describes the effects of signals
on other functions, and contains:

    If the action of the signal is to invoke a signal-catching
    function, ... the original function is said to be *interrupted* by
    the signal.

This, and other wording in 3.3.1.4 makes it clear, I think, that the
bit about EINTR in the description of read() does not apply to job
control signals that were not caught.

I'd suggest that the original poster point this out to the vendor's
customer support people.

David A. Willcox        "Just say 'NO' to universal drug testing"
Motorola MCG - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534


Volume-Number: Volume 31, Number 40

From [e-mail]  Thu Apr 22 19:04:32 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03826; Thu, 22 Apr 93 19:04:32 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29339; Thu, 22 Apr 93 19:04:22 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: POSIX.2: what should 'printf "%c" 3' print?
Organization: Project GLUE, University of Maryland
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 22 Apr 1993 15:52:58 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

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

Several people have complained that the GNU printf program (part of
the GNU shell utilities) handles %c in a less than useful way: it
treats the argument as a string and prints the first character.
That is how I had interpreted POSIX.2; in particular, this paragraph
from the printf section of draft 11.2:

 The argument operands shall be treated as strings if the corresponding
 conversion character is b, c, or s; otherwise, it shall be evaluated as a
 C constant, as described by the C Standard {7}, with the following
 extensions:

I have heard that Chris Torek's BSD printf program does the same thing
with %c, but I haven't verified that myself.

What people would like %c to do is for 'printf "%c" 3' to print a
control-c character (using ASCII) rather than a digit.

I am a little confused now, because the table in section 2.12 that the
printf section refers to for most of its specification says:

    c           The integer argument shall be converted to an unsigned
                char and the resulting byte shall be written.

Can someone clarify what the %c conversion should do?


Volume-Number: Volume 31, Number 39

From [e-mail]  Tue Apr 27 14:00:47 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17243; Tue, 27 Apr 93 14:00:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20186; Tue, 27 Apr 93 13:59:59 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Prsentation on "Standards for Unix" - Help
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Apr 1993 10:51:16 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jacob John)

I am preparing a literature review on the topic "The Development and
Current Status of Standards for Unix" as part of my masters course.
Unfortunately I am unable to find useful references on the above topic.

Could anyone in the newsgroup help me to locate references for the
above topic. I would appreciate names of books, magazines, articles etc.
related to the above topic. Any information on the above topic will be
very helpful.

Thanks in advance

Jacob John

email: [e-mail]

phone: [phone]          level 4 121 Macquarie Street
fax:   [phone]          Sydney 2000.



Volume-Number: Volume 31, Number 42

From [e-mail]  Tue Apr 27 14:01:47 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17456; Tue, 27 Apr 93 14:01:47 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02171; Tue, 27 Apr 93 14:01:33 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: POSIX.2: what should 'printf "%c" 3' print?
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Apr 1993 10:48:32 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Richard A. O'Keefe)

In article <[e-mail]>, [e-mail] (David J. MacKenzie) writes:
> Several people have complained that the GNU printf program (part of
> the GNU shell utilities) handles %c in a less than useful way: it
> treats the argument as a string and prints the first character.
> That is how I had interpreted POSIX.2; in particular, this paragraph
> from the printf section of draft 11.2:

Just speaking as a user:  I have my own printf(1L) and have had since before
Chris Torek's came out.  Mine was intended to be as much like C's as it
could be, and in particular it was important that
    printf %c 10
should write a linefeed.  In the current version of my printf(),
any time that C's printf would accept an integer, mine accepts
any expression that M4's eval() would accept, so
    printf "%c" "'\n' == 10 ? 10 : 13"
does something useful.  It was ever so simple to make this work, and has
not significantly increased the size of the program.  (That code is free...)

> I have heard that Chris Torek's BSD printf program does the same thing
> with %c, but I haven't verified that myself.

I just tried it, and yes, it _does_ do that rather useless thing.
If we wanted that, we could use
    printf %.1s 3
To quote the on-line manual page:
    Printf duplicates (as far as possible) the standard C
    library routine of the same name, at the shell command level.
If it botches %c like this, then it _doesn't_ duplicate printf(3s) at
command level.


Volume-Number: Volume 31, Number 41

From [e-mail]  Tue Apr 27 17:43:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19085; Tue, 27 Apr 93 17:43:13 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20224; Tue, 27 Apr 93 17:42:55 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re:  Prsentation on "Standards for Unix" - Help
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Apr 1993 14:34:31 -0700
Reply-To: [e-mail]
To: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey S. Haemer)

Jacob,

I can.  Give me a ring.  Oh sorry. :-)

Articles appear regularly in this newsgroup reviewing the status
of a number of UNIX standards activities.

The Usenix members' newsletter, ;login:, has a monthly section on this
stuff.

Jim Isaak at Digital has a monthly "Open Systems Tracking Report"
that gives information like this, too.

IEEE Computer has a periodic column on standards that includes the
POSIX work.

Sun Expert has a regular standards column by Peter H. Salus.

There are a number of existing POSIX standards available from the IEEE
and ISO.  (I believe these are also Australian National Standards.)

John Quarterman and Susanne Wilhelm have a lovely book out on the
general topic, published by Addison-Wesley.

UniForum has a fine "POSIX Explored" series.

etc.

Regards,
Jeff

[ And, of course, this is an extremely convenient place for the
  the moderator to point out that all articles are archived on
  ftp.uu.net, in ~ftp/usenet/comp.std.unix -- mod ]

Volume-Number: Volume 31, Number 43

From [e-mail]  Thu Apr 29 19:23:05 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21523; Thu, 29 Apr 93 19:23:05 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00377; Thu, 29 Apr 93 19:22:58 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10100; Thu, 29 Apr 93 16:21:36 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: POSIX Guide
Organization: USENIX
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 29 Apr 1993 10:43:41 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.0: POSIX Guide


Kevin Lewis <[e-mail]> reports on the April
19-23, 1993 meeting in Irvine, Ca.:

Let me say right up front that this was quite a productive
week for the group. Our primary goal was to achieve in
excess of 75% in our affirmative ballots so as to move into
recirculation prior to the next meeting in July.  The group
was successful in achieving this goal. The chronology is as
follows:

   + initial number of affirmative ballots received was 28
     out of 58, placing the percent affirmative at 48%

   + the group converted 7 ballots to affirmative prior to
     the April meeting

   + the group converted 13 ballots to affirmative during
     the April meeting

   + this places the current percent affirmative at 82% (48
     out of 58)

The issue of public specifications, expected to be a highly
significant issue, proved to be exactly that for only a
small number of balloters (five out of 58, three of whom
could be considered negotiable).

The POSIX.0 group conducted a Birds-of-a-feather (BOF)
session on this issue of public specifications to ensure
that any balloter and any one else with a concern in this
area had an opportunity have a dialogue with Dot Zero to
ensure an effective exchange of information.  Our main
concern prior to this BOF was that the way POSIX.0 sees
public specs and their use and the way everyone else sees
this issue might be at odds.

It became evident after the BOF that the understanding on
this was mutual.  In fact, there were a very small number of
people (3 out of about 20 that attended) who had any major
concern with this topic.

The ISO WG15 Rapporteur and the SC22 Secretariat
representative were present during the BOF. I queried them
on whether or not there was any concern expressed on this
issue at their respective levels within ISO.  They both
indicated that each group was aware of the presence of this
topic in the POSIX.0 guide and no one had expressed any
concern.

Given that POSIX.0 has reached the goal enabling a
recirculation, this will be coordinated with the IEEE with
the objective of having this next phase start prior to the
July meeting in Denver.  The group will be in recirculation
during the July meeting. So our discussions will focus on
possible future projects, to include a guide in the area of
Transaction Processing and an IEEE video conference that
would serve as a tutorial about the use of the guide.


Volume-Number: Volume 31, Number 44

From [e-mail]  Thu Apr 29 19:23:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21540; Thu, 29 Apr 93 19:23:18 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00431; Thu, 29 Apr 93 19:23:01 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10122; Thu, 29 Apr 93 16:21:44 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.4: Real Time
Organization: USENIX
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 29 Apr 1993 10:49:46 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.4: Real Time


Bill O. Gallmeister <[e-mail]>, vice chair of the
POSIX.4 working group. reports on the January 11-15, 1993
meeting in New Orleans, LA:

POSIX.4 has, for all intents and purposes, split into two
separate groups.  On the one hand, we have the existing,
``old'' work of POSIX.4: POSIX.4 itself, POSIX.4a (threads),
and POSIX.13.  These three documents are in balloting right
now and are not, for the most part, the concern of the
working group.  On the other hand, the working group is
busy, mostly with POSIX.4b, a proposal for extended real-
time functionality.  POSIX.4b is what the working group
worked on in New Orleans.  This report will briefly cover
both parts of POSIX.4.

What We Work On

First, here's a brief introduction to what we do in POSIX.4.
POSIX.4, the working group charged with making extensions to
POSIX to support real-time applications, has a sizable
stable of proposed standards in its estate.  POSIX.4 is the
basic realtime standard;  POSIX.4a is the threads extension
to POSIX;  POSIX.13 is the profiles document that describes
POSIX for everything from an embedded controller to a large
workstation-based real-time system;  POSIX.4b is yet more
real-time extensions (stuff we couldn't agree to work on for
POSIX.4);  and finally, POSIX.4c is the Language-Independent
spec and the test assertions for POSIX.4. [Ed. note the
comments in the editorial on these matters]

The Old Stuff:  POSIX.4.

POSIX.4 is the base, real-time standard.  This document is
so close to finishing, we can taste it!  On the last ballot,
we achieved an 83% affirmative approval rating.  By that
metric, we're done.  On the other hand, some of the
remaining balloters are vociferous and represent large,
existing bases of UNIX functionality.  For this reason, in
New Orleans the technical reviewers were still addressing
the remaining objections, trying to remove as many of these
as possible.  At the close of the New Orleans meeting, the
ballot resolution process wasn't completed.  However, since
then, the resolution process has been finished, and we have
in fact sent out POSIX.4 for its final recirculation.  Two
large changes were made from draft 13 to draft 14, along
with several minor changes.  The major changes are:

  1.  The real-time files chapter has been removed from the
      document.  This chapter had become the lightning rod
      for the majority of the remaining objections, most of
      which objected to the fact that the facility only
      seemed able to do contiguous, pre-allocated disk
      files.  More capability and extensibility was desired.
      A competing proposal, for a thing called fadvise, has
      been made by one of the objectors, and it seems like a
      better solution to the whole issue of real-time files.
      We will probably be addressing this area in future
      work of the POSIX.4 working group.  Unfortunately, for
      now there is no proposal in place for real-time files.
      I was personally uncomfortable with this action, it
      being late in the balloting process.  At the same
      time, though, I do like the fadvise interface more
      than the POSIX.4 Draft 13 interface, and some of the
      Draft 13 facilities were, frankly, incomprehensible to
      me. Basically, I think this action was OK.

  2.  Some of the POSIX.4 interfaces feature the capability
      to set up ``something'' that will cause the
      application to be asynchronously notified in the
      future.  For instance, a timer expiration, or
      asynchronous I/O completion, both result in
      asynchronous notification.  As of draft 13,
      ``asynchronous notification'' meant a signal was
      delivered.  Several objectors wanted the ability to
      replace signals with other, presumably more
      lightweight methods of asynchronous notification
      (simply calling a function is a possibility).  Draft
      14 has been accordingly modified to support extension
      to new methods of asynchronous notification.  Signals
      are currently the only known method of asynchronous
      notification, but other, future mechanisms can now be
      implemented in a portable fashion under the POSIX.4
      facilities.  I am quite in favor of this change, as
      everyone knows there are faster ways of doing
      asynchronous notification than signals!

In addition, there are numerous, very minor changes to draft
14 of POSIX.4.  At this writing, POSIX.4, Draft 14 has been
sent out for one last recirculation.  Draft 14 is not a
complete draft;  it is merely a set of changes from Draft
13.  There are about ten pages of changes.  The balloting
period has already closed, and we are in the process of
totaling up the responses to this last recirculation.

More Old Stuff:  POSIX.4a.

POSIX.4a is the threads proposal.  This document is probably
of greater interest to a lot of the Usenix members than
POSIX.4 itself.  Here's a shocker:  POSIX.4a has gone out
for a recirculation!  After a long while in ballot
resolution, the threads proposal was just recently sent out
again.  It should be in the hands of the balloting group for
another recirculation before this report is published.  With
any luck, this recirculation will go more smoothly, and more
swiftly, than the previous two recirculations have.  The
good news is, this time, POSIX.4a is being recirculated, not
reballoted.  The previous time around, POSIX.4a was re-
balloted.  What that means is, the entire draft was open for
comment.  In a recirculation, by contrast, only the changed
parts of the proposal can be commented upon.  A reballot is
required when not enough people deliver an affirmative
ballot.  Thus, if you need a reballot, you're in trouble.
The fact that we are re-circulating POSIX.4a is a good sign.

Yet more Old Stuff:  POSIX.13.

The profiles document, POSIX.13, is currently still in
ballot resolution.  It seems to be following the POSIX.4a
model, wherein the technical reviewers have very little time
for technical review.  The issues for POSIX.13 are fewer
than for POSIX.4a -- that's good.  On the other hand, the
one big issue, subsetting of POSIX.1, is still to be
addressed.  That's bad.  (For those of you who are just
learning about the POSIX.4 world, POSIX.13 consists of four
profiles, ranging from supercomputer real-time all the way
down to tiny, embedded systems.  These embedded systems
generally run on hardware that is not capable of supporting
all of POSIX.1 and POSIX.2 (no disk, no MMU, very little
memory, etcetera).  For that reason, there is a need for an
embedded profile to call out a subset of POSIX.1:  it needs
a lot of POSIX.1, but other parts are simply irrelevant or
impossible).  Stay tuned for more information on how
POSIX.13 is doing!

POSIX.4c

Some progress has been made towards a language-independent
specification for POSIX.4.  However, given the current
instability of the whole LI thing, I wouldn't be surprised
if we were able to drop this work later on.  For now, work
continues on LI.


Volume-Number: Volume 31, Number 47

From [e-mail]  Thu Apr 29 19:32:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21936; Thu, 29 Apr 93 19:32:18 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03877; Thu, 29 Apr 93 19:32:02 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10108; Thu, 29 Apr 93 16:21:39 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.18: POSIX Platform Environment Profile
Organization: USENIX
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 29 Apr 1993 10:46:07 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.18: POSIX Platform Environment Profile


Paul Borman <[e-mail]> reports on the April 19-23, 1993
meeting in Irvine, Ca.:

The Reduction Continues.

At the April meeting in Irvine, the POSIX.14 group dedicated
one day to the POSIX.18 draft.  It was much easier to work
on the draft this time, mostly due to its reduced size.  As
before, the major work done on the draft was reducing the
number of words.

First of the areas we attacked this meeting was the
introduction and scope.  We decided that even though the
content was basically hidden in there someplace, we would do
best by just re-writing the introduction and scope instead.

The next section of the document looked at was the
definitions section.  After reviewing the definitions of
conformance, we moved them to the conformance section of the
document.  We also removed several definitions that were
either defined in one of the base level standards we
reference, or were actually simply definitions of English
words, such as portability.

In the actual normative text, we moved some of the pieces in
the ``Language Interoperability'' section to our
``Coherency'' section.  This was done to clarify and not
change content.  The only actually substantial change was to
remove the FIPS 151-2 requirements for CS7, CS8, CSTOPB,
PARODD and PARENB, which were added at the last meeting.  It
was brought to our attention that this was required by NIST
to facilitate their RS-232 loop back test.  We decided it
was not appropriate for this profile to require a particular
hardware interface.

We had some discussion on the FORTRAN Language option when
we realized that as the document stood we referenced FORTRAN
77, specified Fortran 90 and required a binding to FORTRAN
77 (POSIX.9).  Although we are not sure what to do for the
final draft, we are sure that it should be consistent.  The
issues are that

  a.  POSIX.9 currently refers to an ANSI standard (FORTRAN
      77) and is not an international standard.

  b.  The International standardized version of Fortran is
      Fortran 90, which is not as widely used as FORTRAN 77,

  c.  this profile is intended to be forwarded to ISO.

The options that we see ahead of us are

  a.  drop the Fortran Language option (not desirable).

  b.  have two Fortran Language options (though only the
      Fortran 90 option would probably make it through ISO,
      or

  c.  Wait for a resolution between POSIX.9 and Fortran 90,
      then do what seems appropriate.

Finally, we actually removed all references to test methods
from the document.  The SEC has rescinded the requirement
for test methods and we had been spending too much time on
it without having satisfactory results.  This also saves 5
full sheets of paper (10 pages).

Once the new editing job has been done, we will probably be
basically ready to go to ballot, but we will have to wait
because our document depends on both POSIX.4a and POSIX.1a.


Volume-Number: Volume 31, Number 45

From [e-mail]  Thu Apr 29 19:32:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21945; Thu, 29 Apr 93 19:32:37 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04094; Thu, 29 Apr 93 19:32:25 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10116; Thu, 29 Apr 93 16:21:42 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: USENIX
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 29 Apr 1993 10:47:56 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.19: FORTRAN-90 Bindings


Michael J. Hannah <[e-mail]>, chair of POSIX.19
reports on the April 19-23, 1993 meeting in Irvine, Ca.:

This was an important meeting for anyone following the
subject of Fortran language bindings to POSIX.  After two
years of effort to drum up interest in a Fortran 90 binding,
the POSIX.9 Working Group proposes to call it quits.  The
few folks who are left believe that there is an insufficient
body of knowledge, practice, or users of ISO/IEC 1539:1991
(Fortran 90) to sustain the effort of producing a POSIX
binding at this time, especially in light of a number of
outstanding technical issues.  Many of these issues concern
trying to determine how best to use the new features of the
Fortran 90 language in a POSIX binding.  However, in a
spirit of one last time, the Working Group postponed until
July the final act that would disband the Working Group.  At
the July POSIX meeting, the Working Group will meet for one
day only, Monday July 12.  Barring a large turnout desiring
to retain the Working Group, the Working Group will
recommend that the executive committee of POSIX withdraw
sponsorship of the Fortran 90 binding project and disband
the group.

The group is circulating a draft of a final report among
members who have participated in the effort so far, and will
present the completed final report at the July meeting.

The probable demise of this working group raises several
questions about POSIX and language bindings:

  1.  How many different languages are likely to bind to
      POSIX?  If this is only a few, does this imply that
      POSIX is less valuable?

  2.  Is POSIX just for C and Ada, and all other languages
      should simply figure out how to call system routines
      in those languages?  Does this make those other
      languages second class citizens in a POSIX world?

  3.  If there are to be future language bindings, should
      the IEEE with its POSIX steering committee sponsor
      that work, or should the committees that define and
      standardize the language (usually part of ANSI X3)
      define those bindings?  There is some discussion of
      Modula 2 and COBOL doing this, and the Fortran 90
      project might be resurrected in X3J3 rather than IEEE
      POSIX.  Is this good or bad?

  4.  Is the lack of interest in Fortran 90 simply a timing
      issue due to the lack of widespread access to Fortran
      90 compilers, or is it due to a lack of interest in
      Fortran 90 itself? or is this just another victim of
      the economy?

There are undoubtedly a wide variety of reasons why there is
insufficient support at this time for this work.  There
could be considerable debate over which reason was the most
significant.  Some would argue that the group should never
have tried to start.  However, it is clear that there is
inadequate support to continue.  I believe it is the
responsible thing to disband this working group.  If you
don't agree, now is the time to speak up.


Volume-Number: Volume 31, Number 46

From [e-mail]  Fri Apr 30 13:47:43 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22360; Fri, 30 Apr 93 13:47:43 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26330; Fri, 30 Apr 93 13:47:41 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA09593; Fri, 30 Apr 93 10:47:40 PDT
From: cimshop![e-mail] (David S. Masterson)
Newsgroups: comp.std.unix
Subject: Re: POSIX.2: what should 'printf "%c" 3' print?
Organization: Consilium Inc., Mountain View, California
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 30 Apr 1993 10:36:26 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David S. Masterson)

Just my two cents:

Shouldn't 'printf "%c" 3' output a NULL byte?  I would expect that the '3'
would be stored in as a 4 byte integer of which the first 3 bytes are '0'.
The '%c' should take the byte at the address of the argument to printf (not
what that argument points to) and output it as an ASCII character (in this
case NULL).  Without testing it, I'm not sure -- is this not what happens?

--
David Masterson                    Consilium, Inc.
[phone]                    640 Clyde Ct.
[e-mail]                Mtn. View, CA  94043

Volume-Number: Volume 31, Number 48

From [e-mail]  Mon May  3 15:49:16 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25794; Mon, 3 May 93 15:49:16 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03520; Mon, 3 May 93 15:49:05 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15499; Mon, 3 May 93 12:49:02 PDT
From: [e-mail] (Damon)
Newsgroups: comp.std.unix
Subject: Re: POSIX.2: what should 'printf "%c" 3' print?
Organization: ExNet Systems Ltd Public Access News, London, UK
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 3 May 1993 12:40:17 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Damon)

In article <[e-mail]> [e-mail] (David S. Masterson) writes:
>Shouldn't 'printf "%c" 3' output a NULL byte?  I would expect that the '3'
>would be stored in as a 4 byte integer of which the first 3 bytes are '0'.
>The '%c' should take the byte at the address of the argument to printf (not
>what that argument points to) and output it as an ASCII character (in this
>case NULL).  Without testing it, I'm not sure -- is this not what happens?

My understanding of printf() as a normal UNIX C library function is
that is prints the byte/character corresponding to the integer passed to
it as in:

    {
    int ic;

    while((ic = getchar()) != EOF) { printf("%c", ic); }
    }

    which should be exactly equivalent to:

    {
    int ic;

    while((ic = getchar()) != EOF) { putchar(ic); }
    }

If %c now behaves like %s then, IMHO, the POSIX group have goofed, big-time.

--
Damon Hart-Davis   [e-mail]   London UK
Tel/Fax: [phone]======Two jobs:
(1) Parallelogram Editor,        [1.42]
(2) Seller of public-access news/mail & cheap Suns (mail [e-mail]).


Volume-Number: Volume 31, Number 49

From [e-mail]  Mon May  3 15:51:24 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26109; Mon, 3 May 93 15:51:24 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04099; Mon, 3 May 93 15:51:17 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15546; Mon, 3 May 93 12:50:52 PDT
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: POSIX.2: what should 'printf "%c" 3' print?
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 3 May 1993 12:41:35 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Richard A. O'Keefe)

In article <[e-mail]>, [e-mail] (David S. Masterson) writes:
> Submitted-by: [e-mail] (David S. Masterson)
> Shouldn't 'printf "%c" 3' output a NULL byte?  I would expect that the '3'
> would be stored in as a 4 byte integer of which the first 3 bytes are '0'.
> The '%c' should take the byte at the address of the argument to printf (not
> what that argument points to) and output it as an ASCII character (in this
> case NULL).  Without testing it, I'm not sure -- is this not what happens?

Recall that
(1) The existing documentation for Chris Torek's printf(1)  -- and the
    undocumented intent of mine, which unfortunately uses proprietary
    Quintus code for the underlying printf() engine -- has it that

    Printf duplicates (as far as possible) the standard C
    library routine of the same name

    In C, printf("%c", 3) writes a byte with value \003 (unless of course
    '\n' == '\003', in which case strange things might happen).  It does
    not write a NUL byte.

(2) There are at least _three_ languages in *IX which have printf():
    (A) C
    (B) AWK -- which is part of .2
    (C) SH -- the printf(1) command
    So we would expect that
    printf "%c" 3
    and
    awk -e 'END { printf("%c", 3) }' </dev/null
    would produce the same results.

(3) Who said that the printf(1) command uses 4 byte integers?

(4) "The '%c' should take the byte at the address of the argument to
    printf".  WHAT address?  In the C equivalent, namely
    printf("%c", 3)
    printf() receives the numeric value 3, not the address of anything.
    Certainly a command line notionally contains no addresses.

(5) For what it's worth, the relevant part of the code in my printf(1)
    looks like this:

long get_integer_arg(operands, size)
    char ***operands;
    int size;
    {
        char *arg = *++*operands;
    long result;

        if (!arg) insufficient_arguments();
        result = expr(arg);        /* copied from PD M4's eval() */
    switch (size) {
        case BYTE_SIZE: return result & 255;
        case HALF_SIZE: return result & 65535;
        case LONG_SIZE: return result;
    }
    }

                    case 'c':
            c = get_integer_arg(&operands, operand_size);
                        /* drop through */
                    default:
literal:                if (precision < 0) precision = 1;
                        if ((field_width -= precision) <= 0) {
                            PUTCHR(c, precision);
                        } else
                        if (justification == GAMMA_PADDING) {
                            PUTCHR(c, precision);
                            PUTCHR(padding_character, field_width);
                        } else {
                            PUTCHR(padding_character, field_width);
                            PUTCHR(c, precision);
                        }
                        break;

    PUTCHAR(char, count) writes out count copies of the character (stored
    in) char.  So, for my implementation, it would make exactly as much
    sense for 'printf %c 3' to write a NUL character as it would for
    'printf "x"' to write a NUL character; the same code handles both.
    The only address here is operands, which is a pointer into argv[].



Volume-Number: Volume 31, Number 50

From [e-mail]  Tue May  4 22:46:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18551; Tue, 4 May 93 22:46:54 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13414; Tue, 4 May 93 22:46:53 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14596; Tue, 4 May 93 19:46:52 PDT
From: [e-mail] (Peter Allan)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: Rutherford Appleton Laboratory
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Peter Allan)
X-Submissions: [e-mail]
Date: 4 May 1993 16:42:03 -0700
To: [e-mail]

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

I was rather surprised and disappointed to hear of the probable demise
of the work on a Fortran 90 binding for POSIX. I have seen a draft of the
proposed Fortran 77 binding and I do not particularly like it. I do not wish
to be critical of the work of that committee as it seems to me that this
is a classic example of "if you want to get there, you should not start
from here" (i.e. Fortran 77). The spirit of Fortran 77 has to be bent to
get a POSIX interface and I had great hopes that a Fortran 90 one would be
a great deal better.

The project that I work for is just beginning to get to grips with
Fortran 90 and it would certainly make the language more attractive if
there was a POSIX binding.

Perhaps this is just a question of timing after all. While it may not yet
seem timely to propose the correct POSIX binding to Fortran 90, it seems
clear to me that it is easy to come up with a binding that is superior to
any possible Fortran 77 binding. It would be most unfortunate if work on
a Fortran 90 binding were delayed to the extent that it affected the take
up of Fortran 90 as a language.

On the technical side, I would not assume that it will be possible to provide
a satisfactory Fortran to C interface on all platforms. An example (of dubious
relevance) is that if you call functions written in Microsoft C from routines
written in Microsoft Fortran, you cannot get hold of the length of a passed
length character argument.

Peter Allan
STARLINK project
Rutherford Appleton Laboratory


Volume-Number: Volume 31, Number 51

From [e-mail]  Wed May  5 13:31:24 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18606; Wed, 5 May 93 13:31:24 -0400
Received: from cygnus.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27692; Wed, 5 May 93 13:31:03 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12410; Wed, 5 May 93 10:14:42 PDT
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 5 May 1993 10:04:35 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>I have seen a draft of the
>proposed Fortran 77 binding and I do not particularly like it.

You're looking at the wrong book; the Fortran 77 standard was approved by
the IEEE Standards Board a while back; copies of the completed IEEE Std
1003.9-1992 have been available for a few months now. You probably still
won't like it, though.

> I had great hopes that a Fortran 90 one would be
>a great deal better.

So did everyone working on 1003.19.

>The project that I work for is just beginning to get to grips with
>Fortran 90 and it would certainly make the language more attractive if
>there was a POSIX binding.

Beat on your Fortran language vendor to provide you with one. This is the
only way there will ever be sufficient existing practice to consider
standardizing such a binding.

> It would be most unfortunate if work on
>a Fortran 90 binding were delayed to the extent that it affected the take
>up of Fortran 90 as a language.

Backwards. If '90 is never taken up as an effective language, never taken up
to the degree that some vendor or vendors take the time to develop POSIX
bindings, then development of a standard POSIX binding will be delayed,
probably permanently. If that degree of uptake doesn't occur, then it's a
good thing the POSIX machinery never wasted time and resources developing a
binding no one wanted or used.

>On the technical side, I would not assume that it will be possible to provide
>a satisfactory Fortran to C interface on all platforms. An example (of dubious
>relevance) is that if you call functions written in Microsoft C from routines
>written in Microsoft Fortran, you cannot get hold of the length of a passed
>length character argument.

This is a language interoperability issue, which is not address by any IEEE
standard. When vendors implement 1003.9, they need merely ensure the correct
semantic things happen; they're not required to implement the F77 equivalent
of open() by calling the C-language open(), they can use assembler magic and
intimate knowledge of their compiler's generated code, etc. The issue of a
function in one language calling a function in another language is a very
difficult issue, ISO is busy inventing solutions over in JTC1 SC22 WG11
(don't hold me to the WG number, it may be WG7).

POSIX, when it's working right, doesn't invent.

Jason Zions
Chair, IEEE P1003.8 Transparent File Access
Disclaimer: This is not an official statement of IEEE P1003.8, IEEE PASC
(its sponsoring body), IEEE-CS, or IEEE.


Volume-Number: Volume 31, Number 52

From [e-mail]  Wed May  5 13:32:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18733; Wed, 5 May 93 13:32:44 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03674; Wed, 5 May 93 13:32:43 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12684; Wed, 5 May 93 10:22:23 PDT
From: [e-mail] (Mike Wulkan)
Newsgroups: comp.std.unix
Subject: Confusing abort() semantics
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 5 May 1993 10:07:23 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Let me set the stage:

1)  ANSI C Standard Section 4.10.4.1 abort():
    "...causes abnormal program termination to occur, unless the signal
    SIGABRT is being caught and the signal handler does not return.  ...
    is returned to the host environment by means of the function call
    raise(SIGABRT)."

2)  Posix .4a Section 2.2.1.136:
    "Asynchronously generated signal: A signal which is not
    attributable to a specific thread.  Examples are signals sent via
    kill(), ..."

3)  Posix .4a Section 8.4.6.2:
    "The C standard raise() function...  The effect of this function in
    a POSIX.4a process shall be equivalent to calling
    kill(getpid(),sig).  The signal specified shall be asynchronously
    generated, regardless of the signal number, providing the signal
    number is valid."

I think that it is pretty clear from the above that abort() causes an
asynchronous SIGABRT signal to be generated.  So how do you achieve the
semantics required by (1) if the SIGABRT signal is delivered to a thread
other than the one that issued the abort() call?  What you end up with
is a race condition between the thread that is executing the SIGABRT
signal handler and the thread that issued the abort() function call
terminating the program!  AND the method of exiting the signal handling
function has NO influence on whether the program will be terminated.
This is a direct violation of ANSI C.

Even in the case where the SIGABRT signal is delivered to the same
thread that issued the abort() function call, since the signal is
asynchronous, there is NO guarantee that it will be delivered before the
abort() function initiates termination of the program.

Can someone please point out something in the ANSI, POSIX.1 and/or
POSIX.4a that gets me out of this quandary?

Thanks,

Mike Wulkan


Volume-Number: Volume 31, Number 53

From [e-mail]  Fri May  7 04:08:12 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21212; Fri, 7 May 93 04:08:12 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11246; Fri, 7 May 93 04:08:09 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26778; Fri, 7 May 93 01:08:05 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 May 1993 00:58:50 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Peter Allan) writes:
>The spirit of Fortran 77 has to be bent to get a POSIX interface and
>I had great hopes that a Fortran 90 one would be a great deal better.

I think the very notion that a POSIX binding should be feasible for an
arbitrary procedural programming language is in error.

Back in the early days of UNIX, a large fraction of the system calls
were supported in the UNIX Fortran library, but people who tried
doing much UNIX system programming in Fortran (and there were a lot
of us) found out pretty quickly that it was a mistake to try to use
the language for purposes for which it was ill suited, and switched
to C for serious system programming.  In Fortran programs we still
occasionally used the system() function but that was about it.


Volume-Number: Volume 31, Number 56

From [e-mail]  Fri May  7 04:08:11 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21210; Fri, 7 May 93 04:08:11 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11224; Fri, 7 May 93 04:08:08 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26772; Fri, 7 May 93 01:08:03 PDT
From: [e-mail] (Ed Posnak)
Newsgroups: comp.std.unix
Subject: POSIX.4 Semaphores
Organization: NASA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 May 1993 00:58:12 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Ed Posnak)

When a process holding a lock is killed (executes _exit) is it
a. required to release the lock so that another process doing a sem_wait()
   can proceed
b. required not to
c. implementation defined
d. none of the above ???

I do not have draft 14, so any help is appreciated.

thanks,

--
Ed Posnak
Harris Space Systems Corporation
[e-mail]


Volume-Number: Volume 31, Number 55

From [e-mail]  Fri May  7 04:08:14 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21216; Fri, 7 May 93 04:08:14 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11278; Fri, 7 May 93 04:08:12 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26784; Fri, 7 May 93 01:08:10 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Confusing abort() semantics
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 May 1993 00:57:29 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Mike Wulkan) writes:
>1)  ANSI C Standard Section 4.10.4.1 abort():
>    "...causes abnormal program termination to occur, unless the signal
>    SIGABRT is being caught and the signal handler does not return.  ...
>    is returned to the host environment by means of the function call
>    raise(SIGABRT)."
>2)  Posix .4a Section 2.2.1.136:
>    "Asynchronously generated signal: A signal which is not
>    attributable to a specific thread.  Examples are signals sent via
>    kill(), ..."
>3)  Posix .4a Section 8.4.6.2:
>    "The C standard raise() function...  The effect of this function in
>    a POSIX.4a process shall be equivalent to calling
>    kill(getpid(),sig).  The signal specified shall be asynchronously
>    generated, regardless of the signal number, providing the signal
>    number is valid."
>I think that it is pretty clear from the above that abort() causes an
>asynchronous SIGABRT signal to be generated.

Yes, to the extent that "asynchronous" is (re)defined as per POSIX.4a,
where it seems to mean "process global".

>So how do you achieve the semantics required by (1) if the SIGABRT signal
>is delivered to a thread other than the one that issued the abort() call?

Well, the first thing to note is that the C standard specifies only what
is guaranteed for STRICTLY CONFORMING programs, which excludes any program
that uses POSIX.4a thread facilities.  So, strictly speaking, there is
no standard requirement imposed by (1) in such circumstances.

>What you end up with is a race condition between the thread that is
>executing the SIGABRT signal handler and the thread that issued the
>abort() function call terminating the program!

Any time you have multiple threads you already have a race.

>AND the method of exiting the signal handling function has NO influence
>on whether the program will be terminated.  This is a direct violation
>of ANSI C.

I didn't understand that comment at all.  Certainly the POSIX.4a
requirement for the implementation of raise() is compatible with the
requirements of the C standard.  And I saw nothing in the cited specs
that requires that abort() be implemented any differently for POSIX.4a
than for POSIX.1.  I have attached my implementation below for your
perusal.

>Even in the case where the SIGABRT signal is delivered to the same
>thread that issued the abort() function call, since the signal is
>asynchronous, there is NO guarantee that it will be delivered before the
>abort() function initiates termination of the program.

I think that is simply a misconception of the way that abort() must
operate.  It is the unintercepted SIGABRT, generated by abort(), that
CAUSES (abnormal) program termination.

In the comments below, "asynchronous" means "asynchronous", not the
POSIX.4a redefinition of the term.

/*
    abort() -- generate an abnormal process termination

    public-domain implementation

    last edit:    13-Dec-1992    [e-mail]

    complies with the following standards:
        ANSI/ISO 9899:1990[1992] (replaces ANS X3.159-1989)
        ISO/IEC 9945-1 (Replaces IEEE Std 1003.1-1988)
        SVID Issue 3
        XPG Issue 3
        AES Revision A

    IMPLEMENTOR NOTE:  abort() must be reentrant for other signals
        that may occur asynchronously, resulting in additional
        calls to abort() from their handler functions.
        Consequently, the STDIO cleanup function must also be
        reentrant or else it must block signals and be serially
        reusable.
 */
#ifdef    __ORCAC__
#pragma lint        -1
#pragma optimize    -1
#pragma noroot
#endif

/* IMPORTANT: Define CLEANUP to invoke your STDIO cleanup function: */
#ifdef    unix
extern void    _cleanup();
#define CLEANUP _cleanup();        /* usual invocation through SVR2 */
#else
#ifdef    __ORCAC__
#define SysIOShutdown    SYSIOSHUTDOWN    /* temporary, for ORCA/C 2.0.0 D6 */
extern pascal void    SysIOShutdown( void );
#define CLEANUP SysIOShutdown();    /* ~C_SHUTDOWN undoubtedly better */
#else
#define CLEANUP /* XXX -- define yours here -- XXX */
#endif
#endif

#define _POSIX_SOURCE    /* force visibility of POSIX.1 symbols, if any */
#include    <signal.h>

typedef void    (*sigf_type)(
#ifdef    __STDC__
                  int
#endif
                );

#ifndef    SIGABRT
#define    SIGABRT    SIGIOT            /* UNIX tradition */
#endif

void
abort(
#ifdef    __STDC__
       void
#endif
     )
    {
    register sigf_type     sigfunc = signal( SIGABRT, SIG_IGN );
#ifdef    SIG_BLOCK            /* POSIX.1 support assumed */
    sigset_t        abort_mask;

    (void)sigemptyset( &abort_mask );
    (void)sigaddset( &abort_mask, SIGABRT );
    (void)sigprocmask( SIG_UNBLOCK, &abort_mask, (sigset_t *)0 );
    /* If a SIGABRT signal was pending, it has now been discarded. */
#endif

    if ( sigfunc == SIG_IGN )
        sigfunc == SIG_DFL;

    if ( sigfunc == SIG_DFL )
        CLEANUP         /* flush STDIO buffers etc. */

    for ( ; ; )
        {
        (void)signal( SIGABRT, sigfunc );
                    /* SIG_DFL or function */
        (void)raise( SIGABRT );    /* wham? */

        /* The program caught SIGABRT and the handler returned. */

        sigfunc = SIG_DFL;    /* force bam! */
        }
    }


Volume-Number: Volume 31, Number 54

From [e-mail]  Fri May  7 13:40:35 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25605; Fri, 7 May 93 13:40:35 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07840; Fri, 7 May 93 13:40:34 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16059; Fri, 7 May 93 10:40:32 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: oops (was: Confusing abort() semantics)
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: abort
X-Submissions: [e-mail]
Date: 7 May 1993 10:31:02 -0700
Reply-To: [e-mail]
To: [e-mail]

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

There was a typo in the PD abort() implementation I posted in this thread:

$ diff abort.c.typo abort.c.fixed
6c6
<     last edit:    13-Dec-1992    [e-mail]
---
>     last edit:    07-May-1993    [e-mail]
73c73
<         sigfunc == SIG_DFL;
---
>         sigfunc = SIG_DFL;    /* bug fix courtesy [e-mail] */

Sorry about that..


Volume-Number: Volume 31, Number 57

From [e-mail]  Mon May 10 19:47:58 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25319; Mon, 10 May 93 19:47:58 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16327; Mon, 10 May 93 19:47:52 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25323; Mon, 10 May 93 16:47:32 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Confusing abort() semantics
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 May 1993 16:32:17 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In further off-line discussion with Mike Wulkan, another bug in my
abort() implementation turned up.  It is necessary to TEST whether
or not SIGABRT is blocked before unblocking it, and if it had been
blocked upon entry to abort() then sigfunc needs to be replaced by
SIG_DFL.  (In other words, a signal handler function should NOT be
invoked when SIGABRT was blocked.)  Since I don't have the POSIX.1
specs at hand at the moment, I'm not providing a code patch, but
from the description here you should be able to fix it yourself.
Or, contact me later once I have had a chance to look up the right
function calls.

Another note:  Although I'm not sure Mike is convinced yet, I
maintain that raise() is specified in the C standard as acting
synchronously, which pretty well moots the issue he raised.  If
the POSIX requirement on its implementation as kill(getpid(),)
leads to problems, then raise() needs to tap into the process
signal vector and directly call the handler function, which meets
the spirit of the POSIX specification and the literal reading of
the C standard's specification.

Why are the POSIX people not coordinating with the C standard
committee(s) when they come up with this stuff?

Volume-Number: Volume 31, Number 59

From [e-mail]  Mon May 10 19:48:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25326; Mon, 10 May 93 19:48:15 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16350; Mon, 10 May 93 19:47:58 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25307; Mon, 10 May 93 16:47:12 PDT
From: [e-mail] ("M.Nielsen")
Newsgroups: comp.std.unix
Subject: POSIX Open Order Plan
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 May 1993 16:30:17 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] ("M.Nielsen")

IEEE's POSIX Standards Update Service
Convenience o Reliability o Savings
The reliable way to get the most current POSIX standards as soon
they're published


New POSIX Standards on the Way

Several new POSIX standards are slated for future publication. Many
cover specific programming language bindings, while others detail
test methods for measuring conformance to POSIX to standardize
other aspects and practices relating to POSIX. And a host of new
POSIX standards projects are currently in development.

You know that implementing the most current, approved IEEE
POSIX standards is intelligent. But many times, it's difficult for you
or your organization to know exactly when a new POSIX standard is
available. Or more importantly, how to obtain a copy fast and at a
reasonable price.

To provide you with the most up-to-date, cost-effective POSIX
standards, IEEE offers a unique service - IEEE's POSIX
Standards Update Service. All you do is complete the order form
or call the number listed below to enroll in the service - we do the
rest!


How It Works

Enroll today and you'll automatically receive one copy of each newly
approved IEEE POSIX standard as soon as it's published, giving you
a jump on your competition, with no hassle.

What's more, you receive your IEEE POSIX standards at a
GUARANTEED 40% DISCOUNT, invoiced with your shipment.
This is an enormous savings that you just won't find anywhere else!

Enjoy the ease and reliability of receiving the newest POSIX
standards as soon as they become available.


To Sign Up . . .

Call Renee Owens at [phone]. Or, if you prefer, simply
return the attached order form with a copy of your purchase order,
stating your intention to enroll in the service. (A purchase order is
required merely to verify enrollment in the program; no dollar
commitment is needed.)


ORDER FORM

POSIX Standards Update Service Enrollment

o Yes, please enroll me in IEEE's POSIX Standards Update Service
(OOP 10). I understand that I'll receive one copy of each published
POSIX standard at a 40% off list price, billed with my shipment, and
that I can cancel my subscription at any time. My purchase order
verifying my enrollment is attached, #___________________.

Name
IEEE Member Number
Company
Street
City    State/Prov.    Zip/Postal Code
Country
Signature

If you prefer, sign up by calling IEEE Customer Service at (908)
562-5432 between 8:00 am and 4:30 pm (EST). Or FAX [phone]
24 hours daily.

Return enrollment form to:    IEEE Customer Service
                Attn: Renee Owens
                445 Hoes Lane, PO Box 1331
                Piscataway, NJ 08855-1331 USA


May 1993


The Institute of Electrical and Electronics Engineers, Inc.
IEEE Standards
445 Hoes Lane, PO Box 1331
Piscataway, NJ 08855-1331 USA


Volume-Number: Volume 31, Number 58

From [e-mail]  Wed May 12 05:32:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09689; Wed, 12 May 93 05:32:37 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21163; Wed, 12 May 93 01:16:00 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA09524; Tue, 11 May 93 22:15:59 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: oops (was: Confusing abort() semantics)
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: abort
X-Submissions: [e-mail]
Date: 11 May 1993 22:04:54 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Ok, here is the latest improvement to the abort() implementation I posted
earlier in this thread:

6c6
<     last edit:    07-May-1993    [e-mail]
---
>     last edit:    11-May-1993    [e-mail]
64c64
<     sigset_t        abort_mask;
---
>     sigset_t        abort_mask, old_mask;
68c68
<     (void)sigprocmask( SIG_UNBLOCK, &abort_mask, (sigset_t *)0 );
---
>     (void)sigprocmask( SIG_UNBLOCK, &abort_mask, &old_mask );
70d69
< #endif
71a71,74
>     if ( sigismember( &old_mask, SIGABRT ) )
>         sigfunc = SIG_DFL;    /* thanks to [e-mail] */
>     else
> #endif


Volume-Number: Volume 31, Number 60

From [e-mail]  Thu May 13 13:33:03 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26334; Thu, 13 May 93 13:33:03 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25379; Thu, 13 May 93 13:32:58 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10256; Thu, 13 May 93 10:32:54 PDT
From: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: POSIX 1003.4 questions
Organization: Network/development platform support, NMTI
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 May 1993 10:16:38 -0700
Reply-To: [e-mail]
To: [e-mail]

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

What is the requirement for the three-argument version of the signal
catching function? I'm not making the assertion that a more complete
AST mechanism would not be useful, but I don't see how this particular
extension provides any useful enhancements. Identification of the cause
of a signal can be provided simply by specifying different signals for
different purposes. Since these enhancements are supposed to be a
*minimal* set of changes, simply specifying a second parameter for an
attached value would have been much cleaner.
--
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
[phone]                            "Na sema Jambo mbwa kali yake leo?"


Volume-Number: Volume 31, Number 61

From [e-mail]  Thu May 13 21:50:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13697; Thu, 13 May 93 21:50:10 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18319; Thu, 13 May 93 21:50:07 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22220; Thu, 13 May 93 18:50:05 PDT
From: [e-mail] (James Buster)
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.4 questions
Organization: Lynx Real-Time Systems, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 May 1993 18:40:22 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (James Buster)

In article <[e-mail]> [e-mail] (peter da silva) writes:
>What is the requirement for the three-argument version of the signal
>catching function? I'm not making the assertion that a more complete
>AST mechanism would not be useful, but I don't see how this particular
>extension provides any useful enhancements. Identification of the cause
>of a signal can be provided simply by specifying different signals for
>different purposes. Since these enhancements are supposed to be a
>*minimal* set of changes, simply specifying a second parameter for an
>attached value would have been much cleaner.

More importantly, the N argument signal handler (where N > 1) and
event handlers from 1003.4 destroy any hope of strict ANSI C
compatibility. It annoys me that the 1003.4 committee would
choose interfaces that require implementation-defined behavior
from the compiler/OS and therefore cannot be truly portable.
Actually, while I'm talking about implementation defined behavior,
what about the 1003.4a functional interface for threads and the 1003.4
events interface? They require that you be able to use a `void *' as data.
One of the committee members told me that you are giving the caller a
"pointers worth of data". In C, pointers do not, and never have,
contained data. This strikes me as being totally bogus.
--
                James Buster
                 [e-mail]

Volume-Number: Volume 31, Number 63

From [e-mail]  Thu May 13 21:50:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13706; Thu, 13 May 93 21:50:15 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18300; Thu, 13 May 93 21:50:06 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22200; Thu, 13 May 93 18:50:00 PDT
From: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: POSIX 1003.4 conflict?
Organization: Network Management Technology, Incorporated
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 May 1993 18:39:32 -0700
Reply-To: [e-mail]
To: [e-mail]

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

What is the relationship between O_APPEND and aio_reqprio on an asynchronous
I/O call? The standard specifies on lines 390 and following that "if O_APPEND
is set... write operations append to the file *in the same order as the calls
were made*." (emphasis mine). On lines 396 and following, it says that I/O is
queued in priority order, and "the aio_reqprio member can be used to lower
(but not raise) the asynchronous I/O operation priority.

Suppose you have a file open for O_APPEND. You issue a write with aio_reqprio
having a positive value, then issue a write with aio_reqprio set to zero.

Lines 396 and following imply the second I/O may occur before the first,
despite O_APPEND being set.

--
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
[phone]                            "Na sema Jambo mbwa kali yake leo?"


Volume-Number: Volume 31, Number 62

From [e-mail]  Sun May 16 17:35:33 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07019; Sun, 16 May 93 17:35:33 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02121; Sun, 16 May 93 17:35:33 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20122; Sun, 16 May 93 14:35:32 PDT
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.4 questions
Organization: Motorola Computer Group, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 May 1993 12:25:11 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (James Buster) writes:

>More importantly, the N argument signal handler (where N > 1) and
>event handlers from 1003.4 destroy any hope of strict ANSI C
>compatibility. It annoys me that the 1003.4 committee would
>choose interfaces that require implementation-defined behavior
>from the compiler/OS and therefore cannot be truly portable.

Read the standard.  There is no conflict with either POSIX.1 or ANSI
C.  The 3-argument signal handler is not used with the ANSI signal()
function; a signal handler established with signal() still gets only
one argument.  You get three arguments only if you establish the
handler using sigaction(), you set the SA_SIGINFO flag is sa_flags,
and you use a field other than sa_handler in the sigaction struct.
(My copy of the last draft isn't handy right now, and I don't remember
the name of the new field.)  The new field has the appropriate
definition for a 3-arg function.

There is no requirement for "implementation-defined" behavior to make
this work.  It can be done portably.

David A. Willcox        "Just say 'NO' to universal drug testing"
Motorola MCG - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534

Volume-Number: Volume 31, Number 64

From [e-mail]  Sun May 16 17:35:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07024; Sun, 16 May 93 17:35:36 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB02127; Sun, 16 May 93 17:35:35 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20128; Sun, 16 May 93 14:35:34 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.4 questions
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 May 1993 12:26:11 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (James Buster) writes:
>More importantly, the N argument signal handler (where N > 1) and
>event handlers from 1003.4 destroy any hope of strict ANSI C
>compatibility.

The real problem is that extra arguments for the same class of functions
that signal() is expected to register for later invocation cannot be
supported on all possible platforms.  This kind of problem is why we
have special <stdarg.h> implementation-provided support for variable-
argument functions, and why X3J11 had to choose between variadic
signal handler function type and one-int argument signal handler
function type (the latter is what was chosen).  I think people have
gotten too used to sloppy programming on systems that let one get
away with it, so that they don't understand why this is a real issue.

>Actually, while I'm talking about implementation defined behavior,
>what about the 1003.4a functional interface for threads and the 1003.4
>events interface? They require that you be able to use a `void *' as data.
>One of the committee members told me that you are giving the caller a
>"pointers worth of data". In C, pointers do not, and never have,
>contained data. This strikes me as being totally bogus.

Actually the C standard requires that there be some integral type
capable of holding a (converted) object pointer such that it can
be converted back to a pointer (of the same type) and compare
equal to the original pointer value.  However, this does differ
from being able to stash an arbitrary integral value into a
pointer.  If one really needs to do that sort of thing, either the
pointer should be taken as pointing to the actual data or else a
union should be used.


Volume-Number: Volume 31, Number 65

From [e-mail]  Sun May 16 17:35:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07037; Sun, 16 May 93 17:35:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02152; Sun, 16 May 93 17:35:38 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20134; Sun, 16 May 93 14:35:36 PDT
Xref: majipoor.cygnus.com comp.std.unix:26 comp.std.internat:30 comp.std.misc:15
From: "M.Nielsen" <[e-mail]>
Newsgroups: comp.std.unix,comp.std.internat,comp.std.misc
Subject: Correction
Followup-To: comp.std.misc
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 May 1993 12:31:10 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jeffrey S. Haemer)

[ Posted again in entirety due to the crosspost.  Please note
  followup's -- mod ]

Seems that there was an error in the phone number on the
POSIX Open Order Plan release, which was not caught until
now.

***** Forwarded message *****

Due to a phone number error, we are sending the IEEE POSIX
Standards Update Service announcement to you again. Please note
that Renee Owen's phone number at IEEE Customer Service is
908-562-5432. We apologize for any inconvenience this may
have caused you.


IEEE's POSIX Standards Update Service
Convenience o Reliability o Savings
The reliable way to get the most current POSIX standards as soon
they're published


New POSIX Standards on the Way

Several new POSIX standards are slated for future publication. Many
cover specific programming language bindings, while others detail
test methods for measuring conformance to POSIX to standardize
other aspects and practices relating to POSIX. And a host of new
POSIX standards projects are currently in development.

You know that implementing the most current, approved IEEE
POSIX standards is intelligent. But many times, it's difficult for you
or your organization to know exactly when a new POSIX standard is
available. Or more importantly, how to obtain a copy fast and at a
reasonable price.

To provide you with the most up-to-date, cost-effective POSIX
standards, IEEE offers a unique service - IEEE's POSIX
Standards Update Service. All you do is complete the order form
or call the number listed below to enroll in the service - we do the
rest!


How It Works

Enroll today and you'll automatically receive one copy of each newly
approved IEEE POSIX standard as soon as it's published, giving you
a jump on your competition, with no hassle.

What's more, you receive your IEEE POSIX standards at a
GUARANTEED 40% DISCOUNT, invoiced with your shipment.
This is an enormous savings that you just won't find anywhere else!

Enjoy the ease and reliability of receiving the newest POSIX
standards as soon as they become available.


To Sign Up . . .

Call Renee Owens at [phone]. Or, if you prefer, simply
return the attached order form with a copy of your purchase order,
stating your intention to enroll in the service. (A purchase order is
required merely to verify enrollment in the program; no dollar
commitment is needed.)


ORDER FORM

POSIX Standards Update Service Enrollment

o Yes, please enroll me in IEEE's POSIX Standards Update Service
(OOP 10). I understand that I'll receive one copy of each published
POSIX standard at a 40% off list price, billed with my shipment, and
that I can cancel my subscription at any time. My purchase order
verifying my enrollment is attached, #___________________.

Name
IEEE Member Number
Company
Street
City    State/Prov.    Zip/Postal Code
Country
Signature

If you prefer, sign up by calling IEEE Customer Service at (908)
562-5432 between 8:00 am and 4:30 pm (EST). Or FAX [phone]
24 hours daily.

Return enrollment form to:    IEEE Customer Service
                Attn: Renee Owens
                445 Hoes Lane, PO Box 1331
                Piscataway, NJ 08855-1331 USA


May 1993


The Institute of Electrical and Electronics Engineers, Inc.
IEEE Standards
445 Hoes Lane, PO Box 1331
Piscataway, NJ 08855-1331 USA


Volume-Number: Volume 31, Number 58






Volume-Number: Volume 31, Number 66

From [e-mail]  Sun May 16 17:35:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07042; Sun, 16 May 93 17:35:41 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB02165; Sun, 16 May 93 17:35:40 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20140; Sun, 16 May 93 14:35:39 PDT
From: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: P1003.4a, pthread_key_create, typo?
Organization: Network/development platform support, NMTI
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 May 1993 12:32:48 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Draft 6, page 73, line 67, in the rationale.

Shouldn't that be

    #define pthread_key_create(key) (0)

since it returns a value, and in the context of a C extension for a private
data type it should always return 0?
--
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
[phone]                            "Na sema Jambo mbwa kali yake leo?"


Volume-Number: Volume 31, Number 67

From [e-mail]  Thu May 20 14:32:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08960; Thu, 20 May 93 14:32:18 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01784; Thu, 20 May 93 14:32:13 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA21532; Thu, 20 May 93 11:32:09 PDT
From: [e-mail] (Ted Baker)
Newsgroups: comp.std.unix
Subject: POSIX Real-Time Ada bindings ballot
Organization: Florida State University Computer Science Department
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Summary: Request for ballot group participants, for POSIX 1003.20 standard
Keywords: Ada, POSIX, real-time, standards, UNIX, ballot
X-Submissions: [e-mail]
Date: 20 May 1993 10:32:14 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Ted Baker)

(Please feel free to repost this information to appropriate electronic
 forums.)


Please find attached the invitation to join the Ada Bindings to the POSIX
Real Time Interfaces balloting group.  There is a $50 (US) fee to join
the balloting group.  Please contact Annamarie Kaczmarek concerning
methods of payment.  To join the balloting group, return the
information requested by this form to the IEEE.  Do not respond to me,
as only the IEEE Standards Office can add you to the ballot group.

Only IEEE or IEEE Computer Society members are eligible to vote on the
standard.  Non-members may participate as a party of interest and
your comments will be given the same consideration as a voting member.

Joining the ballot group is a commitment to respond to the ballot.  Please
do not join the ballot group unless you intend to respond.  If you wish to
obtain a copy of the draft standard without balloting on the standard, you
may order the copies from the IEEE.

Jim Lonjers
Chair, P1003.20 (IEEE Working Group 1003.5)

---------------------------------------------------------------------------
Portable Application Standards Committee
of the IEEE Computer Society Invites You to Ballot On

P1003.20 Standard for Information Technology - - POSIX Ada Language Interfaces
-- Part 1:  Binding for Realtime Extensions

RETURN DEADLINE:        7 JUNE  1993


SCOPE:          To provide an Ada language binding to the realtime POSIX
                standards.

PURPOSE:        To provide capabilities so that a realtime application program,
                written in the Ada programming language:
                a)  Can emply POSIX realtime extensions, and,
                b)  Can operate identically on all conforming
                    POSIX/Ada/Realtime environments


Your Category of Interest in this Standards Ballot:

        User            Producer        Academic        General Interest

(Please choose only ONE of the above.  If you have any combination of
Interests, check the General Interest Category)

Name:                                                   Phone:
Company
Mailing Address
FAX:                                                    EMail:

IEEE or Computer Society Membership Number*:
Check here if NOT a member of IEEE or the Computer Society
[One of the two above lines must be filled out]

*Only IEEE or Computer Society members are eligible to ballot on IEEE proposed
Standards; non-members can participate as Non-Voters

Signature:                                               Date

If you want positive confirmation back by mail that this form has been
received by the IEEE Standards Office, please enclose a stamped,
pre-addressed post card along with this form.

Please return to:               Annamarie Kaczmarek
by                              IEEE Standards Office
7 JUNE 1993                     445 Hoes Lane, P.O. Box 1331
                                Piscataway, NJ  08855-1331
                                FAX:  [phone]


DEPENDENT DOCUMENTS


Following is the list of dependent documents which would be useful for review
for the enclosed Invitation.

For P1003.20 Standard for Information Technology -- POSIX Ada Language
Interfaces -- Part 1:  Binding for Realtime Extensions

Dependent documents are:

1)      P1003.4/D14- March 1993  Draft Standard for Information Technology -
        Portable Operating System Interface (POSIX) - Part 1:  System
        Application Program Interface (API) - Amendment 1:  Realtime
        extension [C Language] (available in June from IEEE)

2)      1003.5-1992 IEEE Standard for Information Technology - POSIX Ada
        Language Interfaces - Part 1:  Binding for System Application
        Program Interface (API) [SH15254]

3)      ANSI/MIL 1815A-1983, Reference Manual for the Ada Programming Language

Balloters may order the IEEE documents by calling toll free at (800) 678-IEEE
in US and Canada.  Outside US and Canada, call [phone] or FAX (908)
982-9667.

For ISO or ANSI standards, balloters may order from following addresses:

        Global Engineering Documents                    ANSI
        15 Inverness Way East                           11 West 42nd Street
        Englewood  CO  80112-5707                       New York, NY  10036
        303/792-2181                                    212/642-4900
        FAX:  [phone]                              FAX:  [phone]

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




Volume-Number: Volume 31, Number 68

From [e-mail]  Tue May 25 15:33:14 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15347; Tue, 25 May 93 15:33:14 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25132; Tue, 25 May 93 15:33:11 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26738; Tue, 25 May 93 12:33:05 PDT
From: [e-mail] ("Paul J. Wanish ([phone])")
Newsgroups: comp.std.unix
Subject: POSIX.1 PAR for Splitting 9945-1
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 May 1993 12:13:24 -0700
To: [e-mail]

Submitted-by: [e-mail] ("Paul J. Wanish ([phone])")

The POSIX.1 Working Group would like to submit a new PAR to split the existing
9945-1 standard. This has come under a lot of attack over the last couple of
years. With this PAR, we hope to segregate the work and make a professional
attempt to satisfy the requirements of groups like the POSIX.4 working group
(while not making a farce of the existing standard). The attached PAR is our
attempt at describing the work. If you plan on participating in this effort
over the next year, please forward your name to me so we can include you on
appropriate meeting notices... Paul
******* PROJECT AUTHORIZATION REQUEST (PAR) ********
* Does this PAR revise a previously approved PAR?:
       YES
* Description of Proposed Document:
       Full Use Standard, Revision of 1003.1
* Project Title:

 Information technology - Portable Operating System Interface (POSIX) -
 Part 1: System Application Program Interface (API)
  Language Independent / C Binding

* Scope of Proposed Standard (Revision)

 To revise 1003.1 subject to the following requirements and
 constraints:

 The features and associated requirements defined by 1003.1 shall be
 partitioned along natural boundaries into separate modules each of
 which shall be:
  1) specified independently aside from explicit dependencies,
     which shall be minimized to the extent possible
  2) functionally complete and separable aside from explicit
     dependencies, which shall be minimized to the extent possible
 A new type of implementation conformance, 'Conforming Subset POSIX.1
 Implementation', shall be defined such that an implementation that
 completely satisfies the requirements of a non-empty set of modules,
 closed under functional and specification dependency, shall be a
 Conforming Subset POSIX.1 Implementation.

 The requirements on a Conforming POSIX.1 Implementation shall not
 be changed.

 The division into modules shall be such that some set of modules
 shall be equivalent to each possible Conforming POSIX.1 Implementation;
 that is, the required part plus all combinations of current options.

 The mandatory and optional parts associated with Conforming POSIX.1
 Implementations shall be identified with the appropriate modules or
 sets of modules.

 New modules shall have compile and execution time announcement
 mechanisms analogous to those defined for existing options.

 All interfaces shall be supported by all Conforming Implementations,
 whether or not the associated functionality is supported.

* Purpose of Proposed Standard (Revision)

 To enable implementations and applications to claim conformance, and
 profiles to require conformance, to meaningful subsets of features
 and functionality defined by 1003.1, without changing the
 requirements on Conforming 1003.1 Implementations and Applications,
 and to require that all assertions of or references to such subset
 conformance be clearly distinguished from assertions of and
 references to full 1003.1 conformance.

* Sponsor

      Technical Committee: PASC
      Society: Computer Society

* Name of Group that will write the Standard:

      P1003.1 Working Group

0. Target Completion Date:

      Q4 1994/Q1 1995

1. Proposed Coordination:  Method of Coordination:
   SCC10                   Circulation of Drafts
   X3J11                   Circulation of Drafts
   SC22/WG15 TAG           Circulation of Drafts

2. Are you aware of any patent, Copyright, or Trademark issues?
      No
3. Are you aware of any standards or projects with similar scope?
      No


Volume-Number: Volume 31, Number 69

From [e-mail]  Wed May 26 02:06:04 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24487; Wed, 26 May 93 02:06:04 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25627; Wed, 26 May 93 02:06:02 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA28839; Tue, 25 May 93 23:06:01 PDT
From: [e-mail] (D. J. Bernstein)
Newsgroups: comp.std.unix
Subject: Re: POSIX Open Order Plan
Organization: IR
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 May 1993 22:47:19 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (D. J. Bernstein)

  (as part of a (possibly illegal) ad for IEEE's POSIX publications)
> You know that implementing the most current, approved IEEE
> POSIX standards is intelligent.

Hmmm. No, I wasn't aware of that.

How much money does IEEE get selling each new POSIX.n? How much money
does IEEE lose organizing the creation of each new POSIX.n?

Is the POSIX series a service to the community, or a cash cow for IEEE?
When a new POSIX.n is proposed, how much of a _disservice_ does it have
to be to the community before IEEE decides that it isn't worth doing?
Or is money the only criterion?

Just curious.

---Dan


Volume-Number: Volume 31, Number 70

From [e-mail]  Sat May 29 02:29:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28926; Sat, 29 May 93 02:29:41 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17863; Sat, 29 May 93 02:29:37 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA09660; Fri, 28 May 93 23:29:37 PDT
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX.1 PAR for Splitting 9945-1
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 May 1993 23:12:23 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
> The requirements on a Conforming POSIX.1 Implementation shall not
> be changed.
> ...
>* Purpose of Proposed Standard (Revision)
> To enable implementations and applications to claim conformance, and
> profiles to require conformance, to meaningful subsets of features
> and functionality defined by 1003.1, without changing the
> requirements on Conforming 1003.1 Implementations and Applications, ...

The primary goal of POSIX.1 was to provide a portable platform that
significant applications programming in a UNIX environment could rely on.
When we considered "subsetting", it was fairly obvious that it ran counter
to this overriding goal.

Another serious drawback to this proposal is that it envisions keeping
all the weird "warts" in the specification, for example what an
interrupted I/O system call returns, atomic pipe buffering, etc.
The only reason these warts are present in POSIX.1 is that we had to
accommodate demands from vendors who already had poorly engineered
existing practice in these areas.  If one were to do a proper job of
specifying minimal, modularized system functionality, certainly such
abominations as the signal mechanism should not be present in the
final design.  While UNIX originally embodied many good ideas, it also
missed on a few significant points, and during commercialization it has
acquired a slew of additional misfeatures.  It would be a severe
disservice to future system evolution to cast such attributes in stone
in the "minimal module" specifications.  I think a MUCH better approach
would be to engineer a new set of specifications for this project,
dropping literal POSIX.1 compatibility as unduly constraining.  Of
course, it would be best if the new specs could be reasonably
implemented on existing POSIX.1-conformant systems, but that is not
the same goal as stated in the PAR.


Volume-Number: Volume 31, Number 71

From [e-mail]  Sat May 29 02:29:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28938; Sat, 29 May 93 02:29:44 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17873; Sat, 29 May 93 02:29:40 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA09666; Fri, 28 May 93 23:29:41 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE Standards Board
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 May 1993 23:13:20 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


IEEE Standards Board


Mary Lynne Nielsen <[e-mail]> reports on the
March, 1993 meeting

The March 1993 IEEE Standards Board meeting was the occasion
for the approval of the largest amount of documents ever
from PASC, the Portable Applications Standards Committee of
the IEEE Computer Society, along with action on other
information pertinent to the development of information
technology standards.

A New Year, a New Board

As this was the first board meeting in 1993, the composition
of the IEEE Standards Board and its committees went through
their annual changes.  Appointment to the Standards Board is
for one year only, although members can be appointed for up
to three years in a row.  As such, there was a melange of
both old and new faces at this meeting.  Of interest to PASC
is the fact that two of its members are now members of the
Standards Board, Lorraine Kevra and Jim Isaak.  Other
Computer Society members include Clyde Camp from
Microprocessors, Gary Robinson and Don Loughry from 802, and
Leonard Tripp from the SCCs. Steve Diamond from
Microprocessors is also a committee member, though not a
board member.  This was also the first meeting run by new
Board vice-president of standards Wally Read (previous Board
vice-president

Marco Migliaro had served for three years, so this was quite
a change).

Wally made a number of changes to the chairs of various
Board committees.  For instance, Gary Robinson is now the
chair of RevCom (the IEEE Standards Board Review Committee,
which approves balloted standards for publication), and
Clyde Camp, who used to be RevCom chair, is now chair of
NesCom (the IEEE Standards Board New Standards Committee,
which approves Project Authorization Requests, or PARs).  As
a matter of fact, very few previous chairs maintained their
positions for this year.  What this means in a practical
sense is that there will be a real change in the dynamic and
in the manner that these committees operate during the year.
Each chair has his or her own way of wanting to run a
meeting, not to mention any extra goals that he or she may
want to accomplish.  This first meeting was a time for
establishing the groundwork for the rest of the year, for
understanding the role of each committee under a new chair
and with different members, and for evaluating the previous
work that a committee may have done.

NesCom

For instance, new NesCom chair Clyde Camp was previously
chair of RevCom.  During his time as RevCom chair, Clyde
instituted a department-wide review of all standards that
were over five years old and that had not been reaffirmed.
That review resulted in the removal of a lot of ``dead
wood'' standards that had been sitting on the books for
years with no changes, no reaffirmations, no revisions, and
no withdrawals.  Clyde is now aiming to do the same thing
for NesCom by examining all PARs that are over four years
old to see if any activity is occurring under them.  This is
directly attached to the IEEE Standards Operations Manual
instruction that a PAR is only active for four years.  It is
uncertain at this time what will result from this review,
but this should become clear in future meetings when NesCom
has a chance to review actual figures about PARs.

NesCom has also appointed a subcommittee to examine the
issue of producing an electronic PAR form.  Jim Isaak is on
this committee and can bring forward PASC's views on this
subject.

NesCom also took some specific action on PASC PARs at this
meeting.  Three PASC PARs were approved and four were not.
The four PARs that were not approved were missing the
original copies of required permission release letters.
This is the kind of seemingly small detail that can stall
approval of a PAR, and working group members should always
make sure to double-check the submissions forms to see that
they have provided all necessary information.

RevCom

RevCom was introduced to PASC activity in a big way by the
approval of 12, count 'em, 12 documents in the 1224 family.
These standards deal with Open Systems Interconnection (OSI)
and X.400 based messaging systems. Congratulations to the
chairs and working group members involved with these
standards; they were produced quickly and were able to be
approved straightforwardly!

These standards will now be fast-track balloted to become
international standards (fast-track balloting takes about
half the time of regular balloting).  This ballot is going
through ISO/IEC JTC1 SC21, which is the international
information technology working group covering information
retrieval, transfer, and management for OSI.

Hopefully, this will result in these 12 standards becoming
international standards before the end of the year.

JTC1 Guide

As mentioned in previous snitches, the IEEE Standards Board
International Committee (IntCom) has been working on guides
on how to develop standards in parallel with other
standards-developing organizations.  The first of these
discusses working with ISO/IEC JTC1 (the international
committee in charge of information technology standards).  A
final version of this guide was approved by letter ballot of
the committee in January.  It contains, among other things,
information relating to the POSIX/WG15 scheme of parallel
development.  It will be made available to any interested
party and will be included on the new IEEE Standards process
automation system.

Mechanized Development

Speaking of which, the IEEE Standards Department is
continuing progress with developing a process automation
system that will make various of its publications available
online and that will eventually serve as a means for
developing standards online through the use of SGML
(Standard Generalized Markup Language). This system is
available currently only through a modem connection (from
2400 bps up to 14.4K bps-V.32bis) and will hopefully be
available through Internet connections in the fall.  Among
the publications available online are the IEEE Standards
Board Bylaws, the IEEE Standards Operations Manual, the IEEE
Standards Style Manual, and the aforementioned IntCom JTC1
Guide.  If you'd like more information about this developing
system, contact [e-mail].

Organizational Representatives

The issue of organizational representatives (ORs, also known
as IRs in PASC) was raised by Gary Robinson on behalf of the
Computer Society last December at the IEEE Standards Board.
The topic was then passed to ProCom for discussion in March.
The subject concerns a recommendation from the Computer
Society Standards Activities Board (SAB) that asked for
revision or clarification of the OR policy to 1) limit OR
voting rights to voting on sponsor ballots of draft
standards, and 2) state that IEEE Standards Board approval
of voting rights for ORs is granted for a specific
standards-development effort identified by one or more
specific PARs.  ProCom began to discuss this item in March.
Among the items mentioned at that time were the growing
number of ORs in the PASC Standards Executive Committee
(SEC), the possibility of approving ORs for a project and
not a committee, the possibility of creating a time limit
for OR terms, and the information the Standards Board may
need to be able to judge qualifications for OR approval.
This topic will be discussed further at the ProCom meeting
in June.

Approved PARs:

   + P1003.15a, Draft Standard for Information Technology-
     Portable Operating System Interface (POSIX)-Part 2:
     Shell and Utilities-Amendment: Batch Environment

   + P1003.21, Draft Standard for Information Technology-
     Portable Operating System Interface (POSIX)-Part 1:
     System Application Program Interface (API)- Amendment:
     Real-Time Distributed Systems Communications

   + P1003.22, Draft Guide to the POSIX Open Systems
     Environment-A Security Framework

Withdrawn PARs:

   + P1238.1, Draft Standard for Information Technology-OSI
     Applications Program Interfaces-Common Connection
     Management and Supporting Functions

Approved Standards:

   + P1224, Standard for Information Technology-Open Systems
     Interconnection (OSI) Abstract Data Manipulation-
     Application Program Interface (API) [Language
     Independent]

   + P1224.1, Standard for Information Technology-X.400
     Based Electronics Messaging Application Program
     Interface (API) [Language Independent]

   + P1224.2, Standard for Information Technology-Directory
     Services Application Program Interface (API) [Language
     Independent]

   + P1326, Standard for Information Technology-Test Methods
     for Measuring Conformance to Open Systems
     Interconnection (OSI) Abstract Data Manipulation-
     Application Program Interface (API) [Language
     Independent]

   + P1326.1, Standard for Information Technology-Test
     Methods for Measuring Conformance to a X.400 Based
     Electronics Messaging Application Program Interface
     (API) [Language Independent]

   + P1326.2, Standard for Information Technology-Test
     Methods for Measuring Conformance to a Directory
     Services Application Program Interface (API) [Language
     Independent]

   + P1327, Standard for Information Technology-Open Systems
     Interconnection (OSI) Abstract Data Manipulation C
     Language Interfaces-Binding for an Application Program
     Interface (API)

   + P1327.1, Standard for Information Technology-X.400
     Based Electronics Messaging C Language Interfaces-
     Binding for an Application Program Interface (API)

   + P1327.2, Standard for Information Technology-Directory
     Services C Language Interfaces-Binding for an
     Application Program Interface (API)

   + P1328, Standard for Information Technology-Test Methods
     for Measuring Conformance to Open Systems
     Interconnection (OSI) Abstract Data Manipulation C
     Language Interfaces-Binding for an Application Program
     Interface (API)

   + P1328.1, Standard for Information Technology-Test
     Methods for Measuring Conformance to a X.400 Based
     Electronics Messaging C Language Interfaces- Binding
     for an Application Program Interface (API)

   + P1328.2, Standard for Information Technology-Test
     Methods for Measuring Conformance to Directory Services
     C Language Interfaces-Binding for an Application
     Program Interface (API)


Volume-Number: Volume 31, Number 72

From [e-mail]  Sat May 29 21:41:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02311; Sat, 29 May 93 21:41:13 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13525; Sat, 29 May 93 21:41:11 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24925; Sat, 29 May 93 18:41:11 PDT
Xref: majipoor.cygnus.com comp.std.unix:33 comp.std.c:296
From: [e-mail] (Mark McWiggins)
Newsgroups: comp.std.unix,comp.std.c
Subject: Standard for time/date representation?
Followup-To: comp.std.c
Organization: Northwest Nexus Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 May 1993 18:27:46 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Some coworkers are working on application that could theoretically
live well into the next century, perhaps even outliving the Unix
standard "seconds since 1/1/70" representation.

I downloaded the description of the latest ISO time standard, but
it doesn't seem to say anything about internal representation of
date/time, only display representation.

So: is there an emerging standard for date/time representation,
and if so where is it?

Thanks in advance.

--
Mark McWiggins        Hermes & Associates        [phone] (voice)
[e-mail]    Box 31356, Seattle WA 98103-1356  [phone] (fax)

[ Note cross-posting, and followup, please -- mod ]

Volume-Number: Volume 31, Number 73

From [e-mail]  Fri Jun  4 18:50:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09142; Fri, 4 Jun 93 18:50:07 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09936; Fri, 4 Jun 93 18:50:15 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14006; Fri, 4 Jun 93 15:49:58 PDT
From: [e-mail] (Jeffrey Haemer)
Newsgroups: comp.std.unix
Subject: Electronic Balloting
Organization: Colorado SuperNet, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Date: 4 Jun 1993 14:20:15 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jeffrey Haemer)

Folks,

A few weeks back, we posted a note asking for your advice and aid
in prototyping software for electronic standards balloting.  We
got it.  Thanks.  Now we want some more.

Here's a shar with a first cut at some balloting software.  Unshar
it, read the README, and the rest should be self-explanatory.
We're looking for advice, bugs, bug-fixes, enhancements, and users.
The shar includes our original post, explaining our goal in more detail.

Jeffrey S. Haemer, USENIX Standards Liaiason    <[e-mail]>
Pat Wilson, SAGE Board Member            <[e-mail]>

========
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#        "End of archive 1 (of 1)."
# Contents:  Environ.pl Mail.pl README ballot balloting.mm vote
# Wrapped by [e-mail] on Fri Jun  4 14:11:16 1993
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Environ.pl' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'Environ.pl'\"
else
echo shar: Extracting \"'Environ.pl'\" \(1773 characters\)
sed "s/^X//" >'Environ.pl' <<'END_OF_FILE'
X# $Id: Environ.pl,v 3.0 1993/06/04 19:53:34 ballot Exp ballot $
X
Xpackage Environ;
X# print the environment
Xsub 'printenv {
X    foreach (sort keys %ENV) {
X        print "$_=$ENV{$_}\n";
X    }
X}
X
X# set environment variables
X#    override and add to the values in ENV
X#    with values specified in a resource file.
X#    The resource file is specified by RESOURCE
Xsub 'setenv {
X    local(@path) = split(m%/%, $0);
X    local($cmd) = pop(@path);
X    %ENV = &'get_arr($cmd, %ENV) unless ($'setenv'guard++)
X}
X
X# fill an array from a specified file
X#    Use the first argument as the name of an environment variable
X#    that points at the keyfile.
X#    If that fails, try a file by the name of arg1
X#    Use the second argument as an array of default values
X#
X#    See setenv() as an example.
X#
X#    BUGS:
X#        I don't get why I can't combine the lines marked with "?".
X#
Xsub 'get_arr {
X    local($keyfile) = shift(@_);
X    local (%arr) = @_;
X    open(KEYS,  $ENV{$keyfile} = $ENV{$keyfile} ?  $ENV{$keyfile} : ("$keyfile.res") ) || return %arr;
X    while (<KEYS>) {
X        chop;
X        ($name, $other) = split(' ', $_, 2);    # ?
X        $arr{$name} = $other;            # ?
X    }
X    close(KEYS) || die "can't close $keyfile: $!, aborting\n";
X    return %arr;
X}
X
X# Test routine.  Invoke it in a driver with
X#    require "Environ.pl";
X#    &Environ'test;
Xsub test {
X    &'setenv;
X    %arr = &'get_arr("foo", %ENV);
X    die "get_arr failed to get ENV\n" unless $arr{HOME} = $ENV{HOME};
X    $arr{HOME} = NULL;
X
X    open(IN, "foo.res");
X    print IN "HOME\tBOGUS\n";
X    close(IN);
X    %arr = &'get_arr("foo", %ENV);
X    die "getarr failed to read foo.res\n" unless $arr{HOME} = "BOGUS";
X    $arr{HOME} = NULL;
X
X    $ENV{"bar"} = "foo.res";
X    %arr = &'get_arr("bar", %ENV);
X    die "getarr failed to read ENV{bar}\n" unless $arr{HOME} = "BOGUS";
X    $arr{HOME} = NULL;
X
X    unlink("foo.res");
X    print "Package tests okay.\n";
X}
X
X1;
END_OF_FILE
if test 1773 -ne `wc -c <'Environ.pl'`; then
    echo shar: \"'Environ.pl'\" unpacked with wrong size!
fi
chmod +x 'Environ.pl'
# end of 'Environ.pl'
fi
if test -f 'Mail.pl' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'Mail.pl'\"
else
echo shar: Extracting \"'Mail.pl'\" \(2375 characters\)
sed "s/^X//" >'Mail.pl' <<'END_OF_FILE'
X# $Id: Mail.pl,v 3.0 1993/06/04 19:53:34 ballot Exp ballot $
X
Xrequire "Environ.pl";
X
Xpackage Mail;
X
X@MAILER = ("/usr/bin/mailx", "/bin/mail", "/usr/bin/mail", "/usr/ucb/Mail");
X
X# get key lines
X#    Return each key value
X#    in the current item in an associative array.
X#    keylines are specified by regular expressions
X#    in a file named by the second argument,
X#    default expressions are supplied in the third.
Xsub 'getkeys {
X
X    local($_, $keyfile, %defaults) = @_;
X
X    %keyline = &'get_arr($keyfile, %defaults) unless ($getkeys'guard++);
X    local(%info);
X    local($*) = 1;
X    for $k (keys %keyline) {
X        $info{$k} = $1 if (/$keyline{$k}/);
X    }
X    return %info;
X}
X
X# get all the mail messages
X#    Toss the entire mail file into an array, one element per message.
X#    Return the array
Xsub 'getmsgs {
X    open(INBOX, $_[0])        || die "can't open $_[0]: $!, aborting\n";
X    local($/) = '';
X    @msg = ();
X    $msg = '';
X    while(<INBOX>) {
X        if (/^From /) {
X            push(@msg, $msg) if $msg;
X            $msg = '';
X        }
X        $msg .= $_;
X    }
X    push (@msg, $msg) if $msg;
X    return @msg;
X}
X
X# mail a message
X#    just a call to the native mail program
X#
X#    BUGS: I worry a bit about the diversity of mail programs
Xsub 'mailx {
X    die "bad call to mailx\n" unless @_ > 2;    # try assert
X    local($sub, $to, @msg) = @_;
X    ($ENV{MAILER}) = grep(-x, @MAILER) unless $ENV{MAILER};
X    $cmd = "| $ENV{MAILER} -s '$sub' $to";
X    open(ACKMAIL, $cmd)            || die "can't open $cmd: $!, aborting\n";
X    print ACKMAIL @msg;
X    close(ACKMAIL)                || die "can't close $cmd: $!, aborting\n";
X}
X
X# Test routine.  Invoke it in a driver with
X#    require "Mail.pl";
X#    &Mail'test;
X
X# default values.  %KEYLINES is probably the wrong set
X@MAILDIR = ("/var/spool/mail", "/var/mail", "/usr/spool/mail");
X%KEYLINE =    (
X        'Checksum',    'Checksum:\s*(\d+\s*\d+)',
X        'From',        '^From:\s*(.*)',
X        'Author',    'Author:\s*(.*)',
X        'ID',        'ID:\s*(\d+)',
X        'Subject',    '^Subject:\s*(.*)',
X        'Vote',        'Vote:\s*(.+)',
X        );
X
Xsub test {
X    setpwent;
X    ($name) = getpwuid($>);        # I dunno, why not?
X    endpwent;
X    &'mailx("Zzazz", $name, "This is the first line\nThis is the second\n");
X    sleep 10;
X    ($maildir) = grep(-e, @MAILDIR);
X    @msgs = &'getmsgs("$maildir/$name");
X    $newmsg = pop(@msgs);
X    %info = &'getkeys($newmsg, "keyline", %KEYLINE);
X
X    die "Bad subject line $info{Subject}\n" if "Zzazz" != $info{Subject};
X    die "Bad recipient line $info{To}\n" if "Zzazz" != $info{To};
X    print "Package tests okay.\n";
X}
X
X1;
END_OF_FILE
if test 2375 -ne `wc -c <'Mail.pl'`; then
    echo shar: \"'Mail.pl'\" unpacked with wrong size!
fi
# end of 'Mail.pl'
fi
if test -f 'README' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'README'\"
else
echo shar: Extracting \"'README'\" \(4209 characters\)
sed "s/^X//" >'README' <<'END_OF_FILE'
X# $Id: README,v 3.0 1993/06/04 19:53:34 ballot Exp ballot $
X
XThis is a cut at balloting software.
X
X
X            INSTALLATION
X
XThe system receiving the votes should have a special id to process
Xthe votes, and votes should be sent to that id (e.g.
X<[e-mail]>).
X
XYou _must_ create an initial, two-column file of valid voters,
X"ids.res".  Each voter needs an id, and must know that id to vote.
X(The format of the file is "ID  Votername".) For IEEE standards
Xballots, for example, you might want to make the list be a list of
XIEEE members and their IEEE membership numbers.
X
XThe system has reasonable defaults, but it's fairly configurable;
Xit lets you use external files to specify what kinds of votes can
Xbe cast, where the mailboxes are, and all sorts of other things.
XUnfortunately, you currently have to read the code to understand
Xhow to configure it.
X
XCurrently, the scripts point at /usr/bin/perl.  If your system has
Xperl someplace else, you'll get non-informative error messages.
X
X
X            WHAT IT DOES
X
XVoters run "vote" to cast ballots.  The recipient of the votes runs
X"ballot" to count ballots.
X
X"vote" insures that the ballot has all the right fields,
Xthen tags a checksum on the end.
X
X"ballot" runs through the incoming mailbox and sorts the votes into
Xbins.  In doing so, it validates the balloter and the checksum,
Xand sends the sender an acknowledgment of the receipt of the vote.
X
X
X        WHAT IT DOESN'T DO: KNOWN PROBLEMS/PROJECTS
X
XThere should be a good configuration and installation script.
X
XCurrently, the scripts point at /usr/bin/perl.  If your system has
Xperl someplace else, you'll get non-informative error messages.
XThis could probably be fixed with a good configuration and
Xinstallation script.
X
XOther software that needs to be written are a utility for tallying
Xvotes and a utility for processing invalid votes.  We have contributed
Xsoftware that parses valid votes once they're binned, but it's not yet
Xready to post.
X
XThe "ids.res" file (and its processing) could be more sophisticated.
XIn particular, if it contained an email address, we could have a
Xdaemon periodically run through the file and send mail noodging
Xthose who haven't yet voted.
X
XKnown problems awaiting future solution are indicated in comments
Xthe code.  Those problems should probably be listed here instead,
Xor at least duplicated here.
X
XCurrently, the first vote from a voter that shows up in the mailbox
Xis the one that counts.  This has two shortcomings.  First, if
Xthe messages arrive out-of-order, this isn't the right choice.
XSecond, we might want to allow people to change their minds, in
Xwhich case we should probably use the _last_ message that arrives.
XPerhaps this should be a configuration or command-line option.
X
XThere should be a man page that doesn't make you read the code to
Xfigure out how to configure things.
X
X"ballot" doesn't make any effort to lock the input mailbox.  That's
Xbecause I don't really know how to do this.  It also doesn't do
Xvery fancy security, for the same reason.  (Currently, "vote" appends
Xa simple checksum to the message which is double-checked by "ballot",
Xand then returned to the sender so that the sender can be certain that
Xthe checksum received was the one sent.)
X
XBecause different groups may want different security levels or
Xalgorithms, perhaps the security/checksumming should be done by a
Xseparate executable that "vote" and "ballot" call as a subprocess.
X
X
X            PHILOSOPHICAL OBSERVATION
X
XIt is arguably ironic that this balloting software, initially
Xdesigned to help ballot standards documents, is in a non-standardized
Xlanguage.  I suspect that the fastest way to whip this suite into
Xshape is to ask that everyone who chooses to comment on this amusing
Xirony accompany the comment with an improvement to the software.
X(Figure, it's either that or we create a group to standardize perl ... :-)
X
X
X                FILES
X
XEnvPkg.pl    A package to get and set environment variables and resources
XMailPkg.pl    A package that handles the mail messages
XREADME        This file
Xballot        Sorts mail file into bins of each kind of vote
Xids.res        A two-column list of folks yet to vote: ID Name
Xvote        script to generate a vote
Xvoted.res    Folks who have already voted, same format as "ids"
END_OF_FILE
if test 4209 -ne `wc -c <'README'`; then
    echo shar: \"'README'\" unpacked with wrong size!
fi
# end of 'README'
fi
if test -f 'ballot' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'ballot'\"
else
echo shar: Extracting \"'ballot'\" \(4819 characters\)
sed "s/^X//" >'ballot' <<'END_OF_FILE'
X#!/usr/bin/perl
X# $Id: ballot,v 3.0 1993/06/04 19:53:34 ballot Exp ballot $
X
Xrequire "Mail.pl";
X
X@MAILDIRS = ("/var/spool/mail", "/var/mail", "/usr/spool/mail");
X%CHOICES  = (
X    YES, "yes",
X    NO, "no",
X    ABSTAIN, "abstain",
X);
X
X%KEYLINE =    (
X        'Checksum',    'Checksum:\s*(\d+\s*\d+)',
X        'From',        '^From:\s*(.*)',
X        'Author',    'Author:\s*(.*)',
X        'ID',        'ID:\s*(\d+)',
X        'Subject',    '^Subject:\s*(.*)',
X        'Vote',        'Vote:\s*(.+)',
X        );
X
X# acknowledge a message
X#    parse out the sender,
X#    return an ack with enough information to let the recipient know
X#    what we actually got.
Xsub ack {
X    local($sub) = "Vote received";
X    local($to) = $Keyline{From};
X    local(@ack) =    (
X            "Received vote:    $Keyline{Vote}\n",
X            "Voter:        $Keyline{Author}\n",
X             "ID:        $Keyline{ID}\n",
X            "Checksum:    $Keyline{Checksum}\n",
X            "Msg subject:    $Keyline{Subject}\n"
X            );
X
X    # optional "To" line formats
X    if ($to =~ /<(\S*)>/) {
X        $to = $1;
X    } elsif ($to =~ /(\S*)\s*\(.*\)/) {
X        $to = $1;
X    } else {
X        return 0;
X    }
X    &mailx($sub, $to, @ack);
X    1;
X}
X
X# 'bin' an individual message
X#    Make sure the vote's legit and acknowledge it,
X#    then toss the message into the bin
X#    indicated in the message's "Vote:" field.
Xsub bin {
X    local($msg) = @_[0];
X    %Keyline = &'getkeys($msg, "keyline", %KEYLINE);
X    local($vote) = $Keyline{Vote};
X    foreach (keys %Choices) {
X        $vote = $_, last if $vote =~ /$Choices{$_}/i
X    }
X    $vote = BAD unless (&valid($msg) && $vote && &ack());
X    $tally{$vote}++;
X    print $vote $msg;
X}
X
X# check out the checksum
X#    Right now, expects messages to end with the two lines
X#        Checksum: nnnn nnnn
X#
X#    where the numbers come from running cksum
X#    on the rest of the message body
X#
X#    BUGS: Okay, okay, this isn't any good.
X#    Still, little point wasting time here
X#    until I know what the right thing to do is.
Xsub cksum {
X    local($msg) = @_[0];
X    return 1;
X    # $*=1;
X    @text = split(/\n\n/, $msg);            # split out the header
X    shift(@text);                    # and dump it
X    @text = split(/^Checksum: /, join(' ', @text));    # now the get the checksum
X    $checksum = pop(@text);
X    $checksum = unpack("%32C*", join(' ', @text));
X}
X
X# clean up
X#    print out the tally;
X#    rewrite the "ids" (yet-to-vote) and "voted" files;
X#    finally close open files
X#    removing any that got created but never used
Xsub clean_up {
X    &tally(%tally);
X    open(IDS, "> $ENV{'ids'}")        || die "can't open $ENV{ids} for write: $!, aborting\n";
X    open(VOTED, ">> $ENV{'voted'}")        || die "can't open $ENV{voted} for append: $!, aborting\n";
X    foreach (keys %Ids) {
X        print { $Voted{$_} ? VOTED : IDS } "$_\t$Ids{$_}\n";
X    }
X    close(IDS)            || die "can't close $ENV{ids}: $!, aborting\n";
X    close(VOTED)            || die "can't close $ENV{voted}: $!, aborting\n";
X    close(BAD)            || die "can't close BAD: $!, aborting";
X    foreach (BAD, $ENV{"ids"}, $ENV{"voted"}) {
X        unlink $_ if -z $_;
X    }
X
X    unlink("BAD") if -z "BAD";
X    foreach (keys %Choices) {
X        close($_)        || die "can't close $_: $!, aborting";
X        unlink $_ if -z $_;
X    }
X}
X
X# all the initialization
X#    open up the input mailbox and the output mailboxes.
X#    note that votes are cumulative
X#
X#    BUGS: needs to lock the input mailbox,
X#    then move it out of the way so ballots aren't counted twice
Xsub initialize {
X    &setenv;
X    die "No valid voters\n" unless %Ids = &get_arr("ids");
X    local(%voted) = &get_arr("voted");
X     foreach (keys %voted) {
X         $Voted{$_}++;
X    }
X
X    ($Maildir) = grep(-e, @MAILDIRS);
X    ($Name) = getpwuid($>);        # I dunno, why not?
X    $ENV{BALLOT_BOX} = $ENV{BALLOT_BOX} || "$Maildir/$Name";
X    $ENV{"voted"} = $ENV{"voted"} || "voted.res";
X    die "No votes\n" if ( -z $ENV{BALLOT_BOX} || ! -e $ENV{BALLOT_BOX} );
X    %Choices = &get_arr("choices", %CHOICES);
X    foreach (keys %Choices) {
X        open($_, ">> $_")        || die "can't open $_ for append: $!, aborting\n";
X    }
X    open(BAD, ">> BAD")            || die "can't open BAD for append: $!, aborting\n";
X}
X
X# tally the votes
X#    just print out the tallies from this batch of mail
X#
X#    BUGS: This is just a debugging tool.
X#    Tallying should be done by a separate process
X#    and go directly to the tally bins.
Xsub tally {
X    local(%tally) = @_;
X    foreach (sort keys %tally) {
X        print "$_=$tally{$_}\n";
X    }
X}
X
X# validate the message
X#    Read the file that matches IDs to voter names,
X#    then check that the message "ID:" field has the right "Name:" field.
X#    and that the checksum matches the message.
X#    Don't allow ballot-box stuffing -- only vote once.
X#
X#    BUGS: May need other checks.
X#
X#    Assumes access to a global %Keyline array,
X#    which is probably the wrong thing to do.
X#    This should all be modularized and stuff.
Xsub valid {
X    local($msg) = @_[0];
X    ++$Voted{$Keyline{ID}} if
X        ($Keyline{Author} eq $Ids{$Keyline{ID}})
X        && &cksum($msg)
X        && !$Voted{$Keyline{ID}};
X}
X
X# read mail messages from mailbox
X# and toss them one-by-one into an appropriate output mailbox
X
X&initialize;
X@msg = &getmsgs($ENV{BALLOT_BOX});
Xwhile($msg = shift(@msg)) {
X    &bin($msg);
X}
X&clean_up;
END_OF_FILE
if test 4819 -ne `wc -c <'ballot'`; then
    echo shar: \"'ballot'\" unpacked with wrong size!
fi
chmod +x 'ballot'
# end of 'ballot'
fi
if test -f 'balloting.mm' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'balloting.mm'\"
else
echo shar: Extracting \"'balloting.mm'\" \(1852 characters\)
sed "s/^X//" >'balloting.mm' <<'END_OF_FILE'
X.\" $Id: balloting.mm,v 1.1 1993/06/04 20:10:15 ballot Exp ballot $
X.\" Uses the mm macro ".PH", but that's all
X.PH "''''"
X.ce
XElectronic Balloting Software
X
XWhat if you could FTP POSIX draft standards and ballot on them from
Xthe comfort of your own keyboard?  No more messy stamps or ink-stained
Xfingers!  No need to wait on the Postal "Service" for the latest
Xdrafts!
X
XWe see a future in which draft standards will be available for
Xanonymous FTP, and balloting can be done by email.  For a variety
Xof reasons -- some sensible, some merely historical -- achieving
Xeither of these advances requires overcoming both political and
Xtechnical barriers.  We'd like to remove the technical barriers.
XAndrew Hume has already demonstrated a prototype solution for
Xelectronic draft distribution.  We'd like to see a prototype for
Xelectronic balloting, and we'd like your help to make this happen.
X
XIt's envisioned that any electronic balloting procedure will need
X(a) authentication at least as good as Snail Mail provides and (b)
Xvote-counting software to make it as painless as possible.
X
XQuick-and-dirty authentication can be as simple as (1) mail the
Xballot-request software, which then (2) generates an encryption
Xkey and (3) sends it, via postal mail (wouldn't want them to feel
X_too_ left out!) to the requester, who then (4) uses the out-of-band
Xkey to encrypt the ballot, which is then (5) decrypted by the
Xballoting software and (6) counted appropriately -- or at least
Xthat's the plan.
X
XWhat's wrong with the plan?  How can it be made better?  How
Xinteresting can the vote-counting software get?  Should it be
Xwritten in perl?
X
XPlease contribute your thoughts, code, etc., and help POSIX balloting
Xstep into the 1990s.
X
X
X.nf
X- Jeffrey S. Haemer, USENIX Standards Liaison    <[e-mail]>
X- Pat Wilson, SAGE Board Member    <[e-mail]>
X.fi
END_OF_FILE
if test 1852 -ne `wc -c <'balloting.mm'`; then
    echo shar: \"'balloting.mm'\" unpacked with wrong size!
fi
# end of 'balloting.mm'
fi
if test -f 'vote' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'vote'\"
else
echo shar: Extracting \"'vote'\" \(836 characters\)
sed "s/^X//" >'vote' <<'END_OF_FILE'
X#!/usr/bin/perl
X# $Id: vote,v 3.0 1993/06/04 19:53:34 ballot Exp ballot $
X
X# send in a ballot
X#    Tags a checksum on the end.
X#
X#    BUGS:
X#        The program should probably save the checksum,
X#        or even the completed ballot, somewhere
X#        so the user can verify that the acknowledgement
X#        matches what was sent.
X#        Right now, I use mail's "set record=" feature for this.
X
Xrequire "Mail.pl";
X
X@KEYWORDS = (Author, ID, Vote);
X
Xdie "Usage $0 ballot address\n" if (@ARGV != 2);
Xopen(BALLOT, $ARGV[0]);
Xwhile (<BALLOT>) {
X    push (@msg, $_);
X    foreach $k (@KEYWORDS) {
X        $keywords{$k}++ if ($_ =~ /^$k/);
X    }
X}
X
Xforeach $k (@KEYWORDS) {
X    unless ($keywords{$k}) {
X        print "$k? ";
X        $_ = <>;
X        redo if $_ =~ /^\s+$/;
X        push(@msg, "$k: $_");
X        next;
X    }
X}
Xpush (@msg, "Checksum: " . unpack('%32C*', join('', @msg)) . "\n");
X
X&mailx("Vote", $ARGV[1], @msg);
END_OF_FILE
if test 836 -ne `wc -c <'vote'`; then
    echo shar: \"'vote'\" unpacked with wrong size!
fi
chmod +x 'vote'
# end of 'vote'
fi
echo shar: End of archive 1 \(of 1\).
cp /dev/null ark1isdone
MISSING=""
for I in 1 ; do
    if test ! -f ark${I}isdone ; then
    MISSING="${MISSING} ${I}"
    fi
done
if test "${MISSING}" = "" ; then
    echo You have the archive.
    rm -f ark[1-9]isdone
else
    echo You still need to unpack the following archives:
    echo "        " ${MISSING}
fi
##  End of shell archive.
exit 0


Volume-Number: Volume 31, Number 74

From [e-mail]  Fri Jun  4 21:38:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15457; Fri, 4 Jun 93 21:38:37 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07363; Fri, 4 Jun 93 21:38:48 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA29366; Fri, 4 Jun 93 18:38:35 PDT
Xref: majipoor.cygnus.com comp.os.research:113 comp.std.unix:35
From: [e-mail] (Sean Burke22)
Newsgroups: comp.os.research,comp.std.unix
Subject: Obtaining the POSIX thread spec?
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp
Date: 5 Jun 1993 00:23:42 GMT
Apparently-To: <[e-mail]>

  How do I get info on the POSIX thread specification?  Are there
any other candidates for a portable C-language thread API out there?

Sean Burke
--

Sean Burke            [e-mail]



From [e-mail]  Thu Jun 17 15:14:38 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23490; Thu, 17 Jun 93 15:14:38 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07028; Thu, 17 Jun 93 15:14:08 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26988; Thu, 17 Jun 93 12:09:18 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, \*(Rh
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Jun 1993 11:35:16 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

I don't believe I ever posted this, so here it is for your enjoyment!
--
Nick Stoughton

USENIX Standards Report Editor

The following text appeared anonymously on a notice board at the Irvine
meeting during the "great LIS debate". It is reproduced here for your
enjoyment...although their may be other conclusions possible!


            The Little Standards Group

Once a hard-working little standards group lived with a group of international
standards organizations, WG15, SC22, and JTC1.  One day they decided to make a
standard for them all to share.

"Who will help me start the standard?" asked the little standards group.
"Not I," said WG15 sheepishly. "Not I" bowed JTC1.  "Not I," grunted SC22.
"Then I will do it myself," said the little standards group.

When she had cut the interface, she asked "Who will help me edit the
standard?" "Not I" growled WG15.  "Not I" smiled JTC1.  "Not I" snorted SC22.
"Then I will do it myself" said the little standards group.

When the standard had been edited, the little standards group asked
"Who will help me ballot the standard?"  "Not I" sighed WG15.  "Not I"
sniffed JTC1.  "Not I" whined SC22.  "Then I will do it myself" said the
little standards group.

Soon the wonderful smell of a freshly baked standard filled the community.
"Now" said the little standards group, "who will help me use the standard?"
"Not so fast," cried WG15. "Before we can use our wonderful standard, we
must first have an LIS for the specification." "Yes!" cried JTC1.  "Absolutely
true." said SC22.  "I can understand that" said the little standards group,
"So, who will help me create this LIS?" "It's your standard, so you must
do it," said WG15. "This is reasonable," said JTC1. "Naturally it is
your task," said SC22.

The little standards group worked on the problem for a while, but was not
able to make progress.  So the little standards group went back to the others.
"I don't think I can do this LIS thing" said the little standards group.
"And I didn't even want to do this LIS thing in the first place.
Even though you want it done, you are unwilling to help.  Why should I do this
thing for you?" asked the little standards group. "You cannot call it a
standard until we say you can." said WG15.  "Regrettably true" said JTC1.
"We agree." chortled SC22.

The little standards group said "Fine. Then it will not be a standard for you;
it will be a standard for me. When you are ready, I will work with you to
create this LIS. Until then, I guess you'll just have to do without." So the
little standards group produced useful and portable applications, while WG15,
SC22, and JTC1 hungrily watched.


Volume-Number: Volume 31, Number 76

From [e-mail]  Thu Jun 17 15:16:39 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23828; Thu, 17 Jun 93 15:16:39 -0400
Received: from cygnus.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27370; Thu, 17 Jun 93 15:16:19 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26982; Thu, 17 Jun 93 12:09:17 PDT
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.5: Ada Bindings
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Jun 1993 11:33:54 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.5: Ada Bindings


Del Swanson <[e-mail]> reports on the
April 19-23, 1993 meeting in Irvine, Ca.:

The POSIX.5 group has been working to produce Ada language
bindings to POSIX standards.  The Ada binding for the
POSIX.1, POSIX.5, has now been published as an IEEE
standard, and we are now working on bindings to the Real-
Time Extensions standards being developed by the POSIX.4
group.

The binding to POSIX.4 Has been designated as POSIX.20.
Draft 1 was circulated for mock ballot last December, and
comments have been incorporated into the document.
Registration for real ballot was open in May and June, and
the ballot draft was to be circulated June 18, with a close
of balloting scheduled for the end of July.  We hope to have
this approved immediately after the approval of POSIX.4.

Meanwhile, work has begun concurrently on the binding to
POSIX.4a (threads extensions).  An initial draft has been
prepared, and was debated at the January meeting.
Significant changes to it are now expected to be put on hold
until the ballot resolutions and the next version of
POSIX.4a.  The POSIX.5 group met with the POSIX.4 group in
January to get an update on the status of the threads work.

Orthogonal to this update, some members of the POSIX.5 group
are becoming concerned about the relationship of the threads
interface and the updates to the Ada standard that is
commonly called Ada 9x.  Some significant changes and
enhancements are expected in the tasking model for Ada 9x,
and in some respects they have adverse impact on the ability
to implement an Ada runtime library using POSIX threads.
These concerns are being provided to the POSIX.4 group, for
consideration in the ballot resolution process.

In April, the group was updated on the interpretation
process for POSIX.5.  A few errors have been found in the
standard by implementers (e.g. missing parameter, missing
function definition, error condition oversights).  The only
way to make ``substantive'' changes, even for errors, is to
revise the standard, which means balloting, etc.  The group
decided to incorporate corrections in our binding for the
updated POSIX.1a.  We have initiated a Project Authorization
Request (PAR) for this work.

The group also composed a coordination ballot in response to
POSIX.4a, the threads extensions.  This is evidently the
first time such a ballot has been submitted.  It grows from
the fact that the POSIX.5 group is a coordination group
listed in the POSIX.4a PAR.  The group consensus was to
object to the proposed standard in seven areas.

  - Issues associated with finding the status of mutexes
    within signal handlers, and the asynch-safety of mutex
    operations.

  - Obtaining the effective priority of a thread which has
    had its priority changed by priority ceiling locking.

  - The relation of the options _POSIX_THREAD_PRIO_PROTECT
    and _POSIX_THREAD_PRIO_INHERIT.  They should be
    independent of one another.

  - The implications of unlocking mutexes not in the reverse
    order of their locking, on the implementation of
    priority protection schemes.  If the standard specified
    LIFO order as normative, implementation of priority
    changes could be very efficient.

  - The scheduling implications for priority changes due to
    priority inheritance.  A special rule should exist in
    the standard to require that an executing thread be
    inserted at the head of the queue for the appropriate
    priority when its effective priority changes due to
    inheritance only.  This is as opposed to explicit
    priority changes, for which the rules are given already
    and require the thread to go to the tail of the queue.

  - The relation of the clean-up routines to thread
    cancellation.  There are times when it should be safe to
    do the equivalent of a longjmp from a cleanup routine.

  - The relation of signal masks to threads and processes.
    We think that there should be an interface to mask
    delivery of asynchronous signals for the whole process.


Volume-Number: Volume 31, Number 75

From [e-mail]  Fri Jun 18 15:02:51 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21702; Fri, 18 Jun 93 15:02:51 -0400
Received: from cygnus.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24921; Fri, 18 Jun 93 15:02:53 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA03877; Fri, 18 Jun 93 12:02:43 PDT
From: [e-mail] (Duke Robillard)
Newsgroups: comp.std.unix
Subject: Standards Update, \*(Rh
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Jun 1993 11:32:11 -0700
To: [e-mail]

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

>           The Little Standards Group
>[...]
>
>The little standards group said "Fine. Then it will not be a standard for you;
>it will be a standard for me. When you are ready, I will work with you to
>create this LIS. Until then, I guess you'll just have to do without." So the
>little standards group produced useful and portable applications, while WG15,
>SC22, and JTC1 hungrily watched.

You know how you can tell this is a fairy tale?  It has a happy ending.


Volume-Number: Volume 31, Number 77

From [e-mail]  Tue Jun 22 13:49:46 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02776; Tue, 22 Jun 93 13:49:46 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06491; Tue, 22 Jun 93 13:49:35 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26621; Tue, 22 Jun 93 10:49:25 PDT
Xref: majipoor.cygnus.com comp.std.unix:39
From: [e-mail] (Larry W. Virden)
Newsgroups: comp.std.unix
Subject: P1003.2 and the grep command
Organization: Nedriv Software and Shoe Shiners, Uninc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Jun 1993 10:21:13 -0700
To: [e-mail]

Submitted-by: [e-mail] (Larry W. Virden)

What does POSIX mean when for grep -s it says to suppress the error
messages ordinarily written for nonexistent or unreadable files.

I assume that unreadable means AT LEAST files whose permissions are not
such that would allow me to read.  But what about things like EISDIR?
This is an error which returns indicating that one is not permitted to
read the file - correct?  May I have grep -s suppress this message as
well?

--
:s
:s Larry W. Virden                 INET: [e-mail]
:s Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614


Volume-Number: Volume 31, Number 78

From [e-mail]  Tue Jun 22 20:02:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07820; Tue, 22 Jun 93 20:02:22 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21536; Tue, 22 Jun 93 20:02:21 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16606; Tue, 22 Jun 93 17:02:18 PDT
Xref: majipoor.cygnus.com comp.std.unix:40
From: [e-mail] (Mike Haertel)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: MD6
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Jun 1993 16:40:39 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Larry W. Virden) writes:
>I assume that unreadable means AT LEAST files whose permissions are not
>such that would allow me to read.  But what about things like EISDIR?
>This is an error which returns indicating that one is not permitted to
>read the file - correct?  May I have grep -s suppress this message as
>well?

Note that the messages usually suppressed by grep -s are the result
of open() attempts, but the EISDIR that Larry is talking about is
what you get when you try to read() and NFS-mounted directory--the
open() succeeds.

So the question is exactly what messages should grep -s suppress?
Clearly, it should suppress EACCES and ENOENT returned by open().
Should it suppress EISDIR returned by read()?  After all, an NFS-
mounted directory is certainly "unreadable"...

--
Mike Haertel <[e-mail]>

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Volume-Number: Volume 31, Number 80

From [e-mail]  Tue Jun 22 20:02:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07837; Tue, 22 Jun 93 20:02:31 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21575; Tue, 22 Jun 93 20:02:27 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16612; Tue, 22 Jun 93 17:02:24 PDT
Xref: majipoor.cygnus.com comp.std.unix:41
From: [e-mail] (Steve Brosky)
Newsgroups: comp.std.unix
Subject: Posix.4, accepted?
Organization: Harris CSD, Ft. Lauderdale, FL
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Jun 1993 16:39:52 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Steve Brosky)

It was my understanding that the IEEE standards review board was meeting in
mid June to decide if the draft 14 of Posix.4 was to be accepted as
a standard.  Does anyone know if this happened?

Volume-Number: Volume 31, Number 79

From [e-mail]  Wed Jun 23 13:32:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17192; Wed, 23 Jun 93 13:32:37 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15047; Wed, 23 Jun 93 13:32:33 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05310; Wed, 23 Jun 93 10:32:31 PDT
Xref: majipoor.cygnus.com comp.std.unix:43
From: [e-mail] (Stephen R. van den Berg)
Newsgroups: comp.std.unix
Subject: setgid() and saved gids, why made impossible?
Organization: Rechnerbetrieb Informatik - RWTH Aachen
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 23 Jun 1993 10:23:33 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Stephen R. van den Berg)

It seems that POSIX 1003.1 describes the semantics for setgid() in
such a way that they *needlessly* cripple certain applications.

As I understand it, POSIX 1003.1 specifies a very useful construction
called "saved user and group ids".

The saved ids principally get set whenever a process performs an execve()
call.  This first causes the effective ids to be set according to the settings
on the binary being executed, and shortly thereafter, the saved ids are
copied over from the effective ids.

This allows graceful switching between the real ids and the saved ids,
because both the real and saved ids will not be affected by subsequent
setuid() and setgid() calls, only the effective ids are changed.

So far, so good.  Then I notice a small problem on the horizon.  When the
program performs a setgid() while the effective uid of the process is zero,
this not only affects the real and effective gid, but it ALSO affects the
saved gid.

Now I can't imagine any program making use of or depending on this
(mis)feature.

Sure, I heard the classical argument, programs like "login" and "su" need
to be able to set the saved gid of a process to prevent security holes.
But that is not true.  They do not need to set it at all.  It would be
more than sufficient if both su and login could only set their real
and effective gids.  When they then subsequently execve() the following
shell (or other program), the saved gid will *automatically* be copied
from the effective gid.

Why do I care, you might wonder.  Well, consider the following:

-rwsr-sr-x  1 root     mail        49152 Mar 12 18:19 /local/bin/procmail
drwxrwxr-x  2 root     mail         1024 Mar 12 18:24 /usr/mail

If procmail is called by user A who is in group B, it then has to
assume the identity of a completely other user (the recipient) in order
to deliver the mail.

Say the recipient is user C in group D.

Then the following SHOULD happen to the ids while it is executing:
                            (- means no change)

Previous event:            uid    euid    suid    gid    egid    sgid

Start procmail            A    root    root    B    mail    mail
initgroups() for user C        -    -    -    -    -    -
setgid(D)            -    -    -    D    D    mail
setuid(C)            C    C    C    -    -    -
access some files for user D
start programs for user D
setgid(mail)            -    -    -    -    mail    -
create a file in /usr/mail
setgid(D)            -    -    -    -    D    -
access some files for user D
start programs for user D
exit


Now, POSIX says that the saved gid changes to D as well when the first
setgid(D) is executed (because the euid is zero).  This makes it *impossible*
to somehow flip back the gid to "mail", like I try to do in the second
setgid() call.

But, I can't delay this setgid(D) call till after the setuid() call because
then I may no longer have permissions to join group D.

This raises these questions:
    - Why did POSIX specify it the way it did?  Any compelling reason?
    - Is there any (fictitious) program that depends on the semantics of
      setgid() being so that it affects the saved gid when being root?
    - Is there any way to accomplish this flipping between two groups
      that I overlooked?
    - If not, can we do anything about the standard (to fix this, I can
      not imagine even one program breaking if we do)?
    - What about this rumoured setrgid() or setregid() call?  Would that
      exhibit the correct behaviour?  Or does it exhibit these
      braindamaged semantics (affecting the saved gid when root) as well?

Any comments/answers/hints appreciated.

--
Sincerely, [e-mail]
Stephen R. van den Berg (AKA BuGless).    [e-mail]

I've never been superstitious!  Knock on wood.


Volume-Number: Volume 31, Number 82

From [e-mail]  Wed Jun 23 13:32:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17197; Wed, 23 Jun 93 13:32:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15058; Wed, 23 Jun 93 13:32:37 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05298; Wed, 23 Jun 93 10:32:28 PDT
Xref: majipoor.cygnus.com comp.std.unix:42
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 23 Jun 1993 10:21:30 -0700
Reply-To: [e-mail]
To: [e-mail]

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

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

   Note that the messages usually suppressed by grep -s are the result
   of open() attempts, but the EISDIR that Larry is talking about is
   what you get when you try to read() and NFS-mounted directory--the
   open() succeeds.

The real lose here (surprise, surprise) is that NFS is the culprit
here.  The correct place for the EISDIR to be returned is to the open
call, not to the read.  Errors should not be returned from read and
write if they can be detected at open time and are thoroughly
non-transient.

--
[phone] (H)      |     Offer to God a sacrifice of thanksgiving
[phone] (W)     -+-      and make good your vows to the Most High.
14 Paulina Street        |     Call upon me in the day of trouble;
Somerville, MA 02144     |       I will deliver you, and you shall honor me.


Volume-Number: Volume 31, Number 81

From [e-mail]  Wed Jun 23 16:25:56 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09161; Wed, 23 Jun 93 16:25:56 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17081; Wed, 23 Jun 93 16:25:44 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17592; Wed, 23 Jun 93 13:25:40 PDT
Xref: majipoor.cygnus.com comp.std.unix:44
From: [e-mail] (Casper H.S. Dik)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: FWI, University of Amsterdam
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 23 Jun 1993 12:52:28 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Casper H.S. Dik)

[e-mail] (Michael I Bushnell) writes:
>The real lose here (surprise, surprise) is that NFS is the culprit
>here.  The correct place for the EISDIR to be returned is to the open
>call, not to the read.  Errors should not be returned from read and
>write if they can be detected at open time and are thoroughly
>non-transient.

No. NFS is not the culprit. You cannot detect this at open time.
When you read a directory, you'll open it with open and read it
with getdents(). When you open a file for reading, you'll use the
exact same open call. You cannot detect this error at open time.

Casper

Volume-Number: Volume 31, Number 83

From [e-mail]  Thu Jun 24 20:33:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA29487; Thu, 24 Jun 93 20:33:27 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07953; Thu, 24 Jun 93 20:33:13 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23751; Thu, 24 Jun 93 17:33:12 PDT
Xref: majipoor.cygnus.com comp.std.unix:45
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Jun 1993 17:16:57 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Casper H.S. Dik) writes:
>No. NFS is not the culprit. You cannot detect this at open time.
>When you read a directory, you'll open it with open and read it
>with getdents(). When you open a file for reading, you'll use the
>exact same open call. You cannot detect this error at open time.

Hmm.  I suppose that makes sense.  I think the optimal solution is
simply to provide getdents, with a standard format, and say that read
on a directory gets you some filesystem-dependent raw format.  There
is no reason to have read return an error for directories at all.


--
[phone] (H)      |     Offer to God a sacrifice of thanksgiving
[phone] (W)     -+-      and make good your vows to the Most High.
14 Paulina Street        |     Call upon me in the day of trouble;
Somerville, MA 02144     |       I will deliver you, and you shall honor me.


Volume-Number: Volume 31, Number 84

From [e-mail]  Thu Jun 24 20:45:59 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA29948; Thu, 24 Jun 93 20:45:59 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11810; Thu, 24 Jun 93 20:45:57 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23979; Thu, 24 Jun 93 17:45:54 PDT
Xref: majipoor.cygnus.com comp.std.unix:46
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: HaL Computer Systems
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 24 Jun 1993 17:21:03 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

Regarding the question of 1003.2 "grep -s" supressing EISDIR for
NFS-accessible directories:

NOTE 1
Remember that 1003.2 does *not* assume its pieces are running on a 1003.1-
conforming system. While it's not a bad idea to reason about 1003.2 behavior
from the standpoint of implementations on 1003.1-conforming systems, keep in
mind that such reasoning is not guaranteed to be reflected in the standard.

NOTE 2
When reasoning about 1003.1-conforming systems, please remember that a sys-
tem which so much as hints at the existence of files or directories accessed
via NFS is no longer strictly-conforming, since accessing files over NFS
doesn't yield the exact set of semantics required by 1003.1.  If you really
need a strictly-conforming system, don't configure NFS into the kernel.

[e-mail] (Michael I Bushnell) writes:
>>The real lose here (surprise, surprise) is that NFS is the culprit
>>here.  The correct place for the EISDIR to be returned is to the open
>>call, not to the read.  Errors should not be returned from read and
>>write if they can be detected at open time and are thoroughly
>>non-transient.

According to 1003.1-1990, EISDIR is only returned when opening a directory
for write or read/write; the standard is silent concerning opening
directories with O_READONLY. It's bad enough that NFS breaks read() (see
below); breaking open() too would have been awful.

[e-mail] (Casper H.S. Dik) writes:
>No. NFS is not the culprit. You cannot detect this at open time.
>When you read a directory, you'll open it with open and read it
>with getdents(). When you open a file for reading, you'll use the
>exact same open call. You cannot detect this error at open time.

When you read a directory in POSIX, you open it with opendir() and read it
with readdir(). That's it; no open(), no getdents().

In this case NFS is indeed the culprit; it breaks the 1003.1 behavior of
allowing an application to read() from a directory. This restriction is
arbitrary; the NFS protocol itself allows it. Making read() fail on
NFS-accessed directories was a tool to catch programs that examined
directories using read() and assuming they knew what the actual structures
in the directory looked like. In a POSIX environment, this restriction is
unnecessary; conforming POSIX applications never try that, using the 1003.1
interfaces instead.

In fact, when 1003.8 (POSIX Transparent File Access) sees the light of
publicationand legitimizes NFS under POSIX (so to speak), this restriction
will *have* to go away if one wishes to claim ones implementation conforms
to 1003.8.  Strictly conforming applications don't try to read() directories
with the assumption that they're doing something equivalent to readdir(),
since the standard doesn't say they can; however, a strictly-conforming
application is allowed to read() a directory for any purpose.

In any event, I'd suspect that the spirit of 1003.2, interpreted with
respect to a 1003.1 implementation that also supports NFS files, would be
that "-s" would suppress EISDIR on a directory, since those implementations
really do place directories in the category of "You can't read this".

However, you should file a Request for Interpretation; contact the IEEE
Standards Department for specific instructions on how to do this. It's a
formal process; until you get an interpretation, anything you hear from
anyone, even the chair or tech editor of 1003.2, is mere opinion.

As usual, I am speaking as an individual technical expert, *not* as a
spokesperson for 1003.8, POSIX, PASC, IEEE-CS, IEEE, etc.

Jason Zions
Chair, 1003.8 POSIX Transparent File Access


Volume-Number: Volume 31, Number 85

From [e-mail]  Sat Jun 26 21:30:39 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03414; Sat, 26 Jun 93 21:30:39 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23727; Sat, 26 Jun 93 21:30:38 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA18851; Sat, 26 Jun 93 18:30:37 PDT
Xref: majipoor.cygnus.com comp.std.unix:47
From: [e-mail] (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: Auspex Systems, Santa Clara
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 26 Jun 1993 18:19:30 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Guy Harris)

>In this case NFS is indeed the culprit; it breaks the 1003.1 behavior of
>allowing an application to read() from a directory. This restriction is
>arbitrary; the NFS protocol itself allows it.

The NFS *protocol* may allow it; however, it may be a pain for some NFS
server to *implement* it (not all NFS servers run on top of UNIX; some
may run on top of OSes that make it a pain to get at the raw data in the
directory).

>In fact, when 1003.8 (POSIX Transparent File Access) sees the light of
>publicationand legitimizes NFS under POSIX (so to speak), this restriction
>will *have* to go away if one wishes to claim ones implementation conforms
>to 1003.8.  Strictly conforming applications don't try to read() directories
>with the assumption that they're doing something equivalent to readdir(),
>since the standard doesn't say they can; however, a strictly-conforming
>application is allowed to read() a directory for any purpose.

If 1003.8 refers to NFS at all, what will it say about the behavior of
file systems mounted from non-POSIX-compliant NFS servers?  I suspect
it'll have to say "you're on your own there, bucko", in which case
suppliers of those servers are free to reject attempts to read from
directories with the NFS READ request (rather than the NFS READDIR
request).

Note also that a strictly-conforming application cannot, of course,
assume that the data it reads from a directory will have any particular
format, unless you either 1) use #ifdefs for the different directory
formats on different file systems (and compensate for byte-order
problems as well), 2) wire knowledge of certain formats into the
application, or 3) make the application programmable enough that
programs written under it have that knowledge wired into them.

(I.e., I suspect the sum total of POSIX-system-programmer misery will be
increased infinitesimally, if it's increased at all, by just saying Thou
Shalt Not Try To "read()" From Directories, Lest Thou Get An Error From
"read()".

I also suspect that having NFS client implementations reject requests to
"read()" from directories will result in more broken programs - e.g.,
programs that don't use "opendir()", "readdir()", and company - being
caught and, hopefully, fixed.)


Volume-Number: Volume 31, Number 86

From [e-mail]  Sat Jun 26 21:30:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03422; Sat, 26 Jun 93 21:30:41 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23733; Sat, 26 Jun 93 21:30:40 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA18857; Sat, 26 Jun 93 18:30:39 PDT
Xref: majipoor.cygnus.com comp.std.unix:48
From: [e-mail] (Larry W. Virden)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: Nedriv Software and Shoe Shiners, Uninc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 26 Jun 1993 18:20:11 -0700
To: [e-mail]

Submitted-by: [e-mail] (Larry W. Virden)

In <[e-mail]> Jason Zions <[e-mail]> wrote:
>Strictly conforming applications don't try to read() directories
>with the assumption that they're doing something equivalent to readdir(),
>since the standard doesn't say they can; however, a strictly-conforming
>application is allowed to read() a directory for any purpose.

So an application needs to do a stat first and determine whether the file
type is one which is permitted to be read() before doing the reading?  Moving
back to the question of the grep -s - is it then permitted for grep to
be silent about the fact that one of the arbitrary character string arguments
is a directory that is being skipped?  Certainly it is permissible for grep
to be silent about the fact that one of said character strings does not exist,
or is not readable.

I guess someone will have to write up one of the interpretation requests.

--
:s
:s Larry W. Virden                 INET: [e-mail]
:s Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614


Volume-Number: Volume 31, Number 87

From [e-mail]  Mon Jun 28 18:17:16 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07338; Mon, 28 Jun 93 18:17:16 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03770; Mon, 28 Jun 93 18:17:12 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06782; Mon, 28 Jun 93 15:17:09 PDT
Xref: majipoor.cygnus.com comp.std.unix:49
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: HaL Computer Systems
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jun 1993 14:46:23 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

In article <[e-mail]> [e-mail] (Guy Harris) writes:
>If 1003.8 refers to NFS at all, what will it say about the behavior of
>file systems mounted from non-POSIX-compliant NFS servers?  I suspect
>it'll have to say "you're on your own there, bucko", in which case
>suppliers of those servers are free to reject attempts to read from
>directories with the NFS READ request (rather than the NFS READDIR
>request).

1003.8 doesn't refer to particular mechanisms used to provide file access in
the normative standard; the informative annexes talk about how some of the
most common mechanisms appear to an application program when viewed through
the eyes of pathconf() and the new set of pathconf() variables that 1003.8
defines.

1003.8 doesn't care about how the file access mechanism is implemented; NFS
implemented on Unix, FTAM implemented on VM/370, DCE DFS on tin cans and
string. It just talks about semantic behaviors applications may or may not
rely upon. An application can inquire if directories can be created below a
certain path; if device files can be created within a particular path; if
can application is guaranteed to retain access to a file it has opened even
if some other process (or itself) unlink()s it; that kind of thing. The
implementation has to arrange for pathconf() and fpathconf() to return
correct answers to these questions based on the actual behavior of the
implementation. The "NFS" annex contains the answers that a typical NFS
implementation returns, but there's no requirement that any actual
implementation return those answers.

>Note also that a strictly-conforming application cannot, of course,
>assume that the data it reads from a directory will have any particular
>format

Quite true, but within the context of the 1003.1 standard, besides the
point.

>(I.e., I suspect the sum total of POSIX-system-programmer misery will be
>increased infinitesimally, if it's increased at all, by just saying Thou
>Shalt Not Try To "read()" From Directories, Lest Thou Get An Error From
>"read()".

Perhaps, but I don't know that anyone has tried to make such a change.

>I also suspect that having NFS client implementations reject requests to
>"read()" from directories will result in more broken programs - e.g.,
>programs that don't use "opendir()", "readdir()", and company - being
>caught and, hopefully, fixed.)

NFS client implementations already do this, and just about all the
applications worth catching are already caught. An application that doesn't
use opendir() et al for reading directories is already outside the scope of
POSIX, so the standard should not (and in fact does not) worry about them.
It would be nice if NFS client implementations diverged as little as
possible from POSIX.

(Unfortunately, or fortunately, the current draft of 1003.8 does not provide
a way for an application to inquire if read() is permitted on directories;
because of the way 1003.8 is structured, this directly implies that the
behavior in question must be that of 1003.1 for the implementation to
conform.)

Jason Zions
As usual, speaking solely as an individual technical expert


Volume-Number: Volume 31, Number 88

From [e-mail]  Mon Jun 28 18:17:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07368; Mon, 28 Jun 93 18:17:23 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03858; Mon, 28 Jun 93 18:17:22 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06817; Mon, 28 Jun 93 15:17:20 PDT
Xref: majipoor.cygnus.com comp.std.unix:50
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: HaL Computer Systems
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jun 1993 14:47:27 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

In article <[e-mail]> [e-mail] (Larry W. Virden) writes:
>>Strictly conforming applications don't try to read() directories
>>with the assumption that they're doing something equivalent to readdir(),
>>since the standard doesn't say they can; however, a strictly-conforming
>>application is allowed to read() a directory for any purpose.
>
>So an application needs to do a stat first and determine whether the file
>type is one which is permitted to be read() before doing the reading?

No. According to 1003.1, *all* file types may be read(). It's only when you
add NFS and try to access files over NFS that the standard becomes
irrelevant, and can detect whatever it wants to however it wants to (wait
for read() to fail with EISDIR or stat() before open()).

>  Moving
>back to the question of the grep -s - is it then permitted for grep to
>be silent about the fact that one of the arbitrary character string arguments
>is a directory that is being skipped?

I think so, but this is just my opinion.

>I guess someone will have to write up one of the interpretation requests.

That's the only way to get a definitive answer. In the interp request, be
sure to point out that the system in question is not 1003.1-conforming, and
that the system prohibits read() of a directory.

Jason Zions
Not an official opinion of any entity other than the author


Volume-Number: Volume 31, Number 89

From [e-mail]  Mon Jun 28 18:17:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07408; Mon, 28 Jun 93 18:17:37 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03914; Mon, 28 Jun 93 18:17:34 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06823; Mon, 28 Jun 93 15:17:26 PDT
Xref: majipoor.cygnus.com comp.std.unix:51
From: [e-mail] (Renato Ghica)
Newsgroups: comp.std.unix
Subject: POSIX sources
Organization: Citibank IBISM
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jun 1993 14:48:08 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Renato Ghica)

are the POSIX sources available to the general public?

I'm in need to re-implement the catalog functions (catopen, catclose,
catgets, etc ..) since the vendor-specific implementation does not
seem to work properly.

I'm hoping that there might be an FTP site or something...just
wishful thinking, maybe.....

thanks


-rg

Volume-Number: Volume 31, Number 90

From [e-mail]  Mon Jun 28 18:17:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07403; Mon, 28 Jun 93 18:17:36 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03907; Mon, 28 Jun 93 18:17:33 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06829; Mon, 28 Jun 93 15:17:31 PDT
Xref: majipoor.cygnus.com comp.std.unix:52
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jun 1993 14:48:42 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Casper H.S. Dik) writes:
>No. NFS is not the culprit. You cannot detect this at open time.
>When you read a directory, you'll open it with open and read it
>with getdents().

Seems to me the REAL culprit is the provision of multiple forms of
the "read" function when one would do.  Reading a directory object
could, for example, return one new-line terminated record in ls -l
format per read() invocation.


Volume-Number: Volume 31, Number 91

From [e-mail]  Tue Jun 29 15:33:52 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25280; Tue, 29 Jun 93 15:33:52 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18440; Tue, 29 Jun 93 15:33:44 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15032; Tue, 29 Jun 93 12:33:39 PDT
Xref: majipoor.cygnus.com comp.std.unix:53
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.22: POSIX Security Framework
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Jun 1993 12:08:56 -0700
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.22: POSIX Security Framework


David Rogers <[e-mail]> reports on the April
19-23, 1993 meeting in Irvine, Ca.:

At the January meeting the Portable Applications Standards
Committee (PASC) approved the Project Authorization Request
(PAR) for POSIX.22 to produce ``A Guide to the POSIX Open
Systems Environment - A Security Framework''

This work has been assigned as a subgroup of POSIX.6
Security Working Group.

The objective is to complete the work started by the
Distributed Security Study group and define a framework for
security within POSIX. This is intended to bring together
the concepts of security as system service enhancements, as
currently addressed by POSIX.6, and as security services in
a distributed environment in a single description of
security.

The work will produce a document that it is planned will
eventually be included in a future version of POSIX.0. It is
also intended to provide POSIX.6 with an aid to identifying
and planning future work.

The April meeting discussed the general concepts of the
framework in terms of the concepts of security domains as
outlined in the White Paper released by the Distributed
Security Study Group last year.

The July meeting will be considering the representation of
security within the POSIX.0 model, and a joint meeting with
POSIX.0 has been arranged to facilitate this. In addition, a
proposal on a method for assessing the impact of security on
existing APIs will be discussed.






















Volume-Number: Volume 31, Number 92

From [e-mail]  Wed Jun 30 18:45:58 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07194; Wed, 30 Jun 93 18:45:58 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00814; Wed, 30 Jun 93 18:45:57 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23442; Wed, 30 Jun 93 15:45:35 PDT
Xref: majipoor.cygnus.com comp.std.unix:54
From: [e-mail] (Eric Blood)
Newsgroups: comp.std.unix
Subject: pathconf()/errno question
Organization: Sierra Geophysics Inc.,  Kirkland, Wa
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Jun 1993 15:33:16 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Eric Blood)

After going over pathconf(), I need something clarified.

In the Posix 1003.1 (90) document the return for pathconf is
documented as follows:

"If 'name' is an invalid value, the pathconf() and fpathconf() functions
shall return -1.

"If the variable corresponding to 'name' has no limit for that path or
file descriptor, the pathconf() and fpathconf() functions shall return
-1 without changing errno."

I have always gone on the assumption that you are never supposed to
set errno.  However, if it is allowed, then pathconf() could be used
as defined.  For example:

...
errno = 0;
if ((foo = pathconf("/tmp/bar", _PC_LINK_MAX)) < 0) {
  if (errno == 0) {
    ... /* No limit */
  } else {
    ... /* Invalid argument */
  }
} else {
  ... /* foo contains a valid limit */
}
...

The documentation for errno (in the same document) is as follows:

"The value of this variable ['errno'] shall be defined only after a
call to a function for which it is explicitly stated to be set and
until it is changed by the next function call.  The variable 'errno'
should only be examined when it is indicated to be valid by a
function's return value.  No function defined in this part of ISO/IEC
9945 sets errno to zero to indicate an error."

Does this mean I'm allowed to set the errno variable or not?  If I'm
able to, then I can use the example code with pathconf().  Otherwise,
what should I do?

--
Eric V. Blood
[e-mail]


Volume-Number: Volume 31, Number 93

From [e-mail]  Thu Jul  1 01:16:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19024; Thu, 1 Jul 93 01:16:27 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07722; Thu, 1 Jul 93 01:16:25 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA02207; Wed, 30 Jun 93 22:16:24 PDT
Xref: majipoor.cygnus.com comp.std.unix:55
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Jun 1993 22:03:10 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Eric Blood) writes:
>The documentation for errno (in the same document) is as follows:
>
>"The value of this variable ['errno'] shall be defined only after a
>call to a function for which it is explicitly stated to be set and
>until it is changed by the next function call.  The variable 'errno'
>should only be examined when it is indicated to be valid by a
>function's return value.  No function defined in this part of ISO/IEC
>9945 sets errno to zero to indicate an error."
>
>Does this mean I'm allowed to set the errno variable or not?  If I'm
>able to, then I can use the example code with pathconf().  Otherwise,
>what should I do?

Pedantic answer:

You have to call a function that will set errno to zero (something
like `kill (getpid (), 0)', and then immediately call pathconf.
Pathconf documents that it might or might not set errno, so now you
can look at it.

Real answer:

You have to set errno anyway to write a correct signal handler;
therefore it's OK to set it here.

    -mib
--
[phone] (H)      |     Offer to God a sacrifice of thanksgiving
[phone] (W)     -+-      and make good your vows to the Most High.
14 Paulina Street        |     Call upon me in the day of trouble;
Somerville, MA 02144     |       I will deliver you, and you shall honor me.


Volume-Number: Volume 31, Number 94

From [e-mail]  Thu Jul  1 21:57:08 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21166; Thu, 1 Jul 93 21:57:08 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02173; Thu, 1 Jul 93 21:57:05 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07422; Thu, 1 Jul 93 18:57:02 PDT
Xref: majipoor.cygnus.com comp.std.unix:56
From: [e-mail] (Robert Durst)
Newsgroups: comp.std.unix
Subject: POSIX Ballot pool forming for Sockets and XTI
Organization: The MITRE Corporation
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Summary: Reply to this message to receive invitation to ballot on IEEE P1003.121
Keywords: IEEE P1003.12 Sockets XTI standard POSIX
X-Submissions: [e-mail]
Date: 1 Jul 1993 18:45:21 -0700
Reply-To: [e-mail]
To: [e-mail]

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

To Whom It May Concern:

The POSIX P1003.12  group is defining a protocol-independent
Application Program Interface for process-to-process
communication.  POSIX requires its standards to be based on
existing practice, and two C-language interfaces are being
standardized by P1003.12.  One is the X/Open Transport
Interface (XTI), and the other is the Sockets interface.  The
group has defined a language-independent specification to
which both C-language bindings conform, and this enables the
two bindings to be presented  within a common framework.
Additionally, the group anticipates that non-C-language
bindings would be developed in  accordance with this
language-independent specification.

The group intends to ballot its draft standard in the
September 1993 time frame.

It is to everyone's benefit that these APIs are incorporated
into POSIX.  Your help is  requested to ensure that they are
incorporated correctly.  You can provide this help by joining
the ballot group and balloting on the standard.

If you are a sockets user or implementor, you should be aware
that a significant amount of semantic information has been
extracted from the Berkeley reference implementation for
incorporation into the specification.  This material should
be reviewed thoroughly.  If you are an XTI expert, the text
in the P1003.12 draft is essentially that of the XTI CAE
specification.  As the draft goes through the IEEE balloting
process, changes will certainly be requested.  The presence
of both Sockets experts and XTI experts in the ballot pool is
essential if these requests are to be handled properly.

Membership in the P1003.12 ballot pool is by invitation.  IF
YOU WISH TO RECEIVE AN INVITATION  to join the P1003.12
ballot pool, either you must already receive POSIX
invitations to ballot on draft standards or you must REPLY TO
THIS MESSAGE so I can make sure you get an invitation.  Once
the ballot pool is formed, it is fixed and cannot be added
to, so reply now.

You DO NOT have to be a member of IEEE to ballot on this
draft standard, however, you must be a member in order to
vote "yes."  Non-IEEE members are considered parties of
interest, and if objections are raised by parties of
interest, we will give them due consideration.

THERE IS A FEE charged by the IEEE to cover the initial
distribution of the document and all subsequent
recirculations.  The document is currently about 400 pages
long, and we expect the fee to be approximately $50.

In order to receive an invitation to ballot on IEEE P1003.12,
reply to this message with your name, address, phone number,
fax number, email address, and IEEE membership  number (if
applicable).


Regards,

Robert C. Durst
Chairman, IEEE P1003.12
[e-mail]


Volume-Number: Volume 31, Number 96

From [e-mail]  Thu Jul  1 21:57:16 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21175; Thu, 1 Jul 93 21:57:16 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02218; Thu, 1 Jul 93 21:57:12 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07428; Thu, 1 Jul 93 18:57:07 PDT
Xref: majipoor.cygnus.com comp.std.unix:57
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Jul 1993 18:44:29 -0700
Reply-To: [e-mail]
To: [e-mail]

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

From [e-mail] (Michael I Bushnell):
>>Does this mean I'm allowed to set the errno variable or not?  If I'm
>>able to, then I can use the example code with pathconf().  Otherwise,
>>what should I do?
>Pedantic answer:
>You have to call a function that will set errno to zero (something
>like `kill (getpid (), 0)', and then immediately call pathconf.
>Pathconf documents that it might or might not set errno, so now you
>can look at it.

This is wrong.  POSIX.1 does not require that any interface
ever set errno to zero.  The quoted text above prohibits
setting errno to zero on an error.  The UNIX and POSIX.1
implementations I'm familiar do not touch errno at all
unless there's an error.

>Real answer:
>You have to set errno anyway to write a correct signal handler;
>therefore it's OK to set it here.

The example code will work fine.  The programmer is allowed to
change errno; it's just an int, after all.  The only restriction
is that errno does not have a special meaning unless the system
has detected and reported an error.

Note that the rules will be different for systems that support
multi-threaded processes, because errno may have to be a
function instead of an integral type.

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

Volume-Number: Volume 31, Number 95

From [e-mail]  Fri Jul  2 14:12:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21893; Fri, 2 Jul 93 14:12:18 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00701; Fri, 2 Jul 93 14:12:11 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06426; Fri, 2 Jul 93 11:12:07 PDT
Xref: majipoor.cygnus.com comp.std.unix:58
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: Motorola Computer Group, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Jul 1993 10:52:01 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (Chuck Karish) writes:
>Note that the rules will be different for systems that support
>multi-threaded processes, because errno may have to be a
>function instead of an integral type.

No, not really.  POSIX.4a (pthreads) has the same requirement for
errno as ANSI C, relaxing a bit the requirement that's in POSIX.1.
POSIX.1 says that errno must be specifically "extern int errno;"
POSIX.4a and ANSI C only require errno to be "a modifiable lvalue that
has type int."  The following both satisfy POSIX.4a and ANSI C, and are
just fine for threads:

    #define errno (*__errno)
    extern int *__errno;

    #define errno (*__errno())
    extern int (*__errno())

The following is NOT fine; it would violate ANSI C:

    #define errno __errno()

David A. Willcox        "Just say 'NO' to universal drug testing"
Motorola MCG - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534


Volume-Number: Volume 31, Number 97

From [e-mail]  Fri Jul  2 17:56:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22254; Fri, 2 Jul 93 17:56:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20765; Fri, 2 Jul 93 17:56:44 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA21280; Fri, 2 Jul 93 14:56:43 PDT
Xref: majipoor.cygnus.com comp.std.unix:59
From: [e-mail] (De Mickey)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: Chemical Abstracts Service, Columbus, Ohio
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Summary: ANSI C requires a writable errno as well
Keywords: errno pathconf strtod strtol strtoul
X-Submissions: [e-mail]
Date: 2 Jul 1993 14:45:50 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (De Mickey)

From previous discussion, it appears that POSIX.1 (in
effect) requires that applications set errno to zero in
order to fully test pathconf() return codes.

I just wanted to point out that the ANSI C has a few
routines with a similar requirement.  strtod(), strtol()
and strtoul() all set errno to ERANGE if the result of the
conversion overflows, underflows, or is not representable.
However, the function return value can look valid (e.g.
zero), so the application must set errno to zero before the
call, and then test errno afterwards, if it wants to be sure
the conversion was successful.

    errno = 0;
    dbl = strtod(ptr, &endptr);
    if (errno != 0) {
       /* complain to someone */
    }

--
De Mickey   Chemical Abstracts Service |
[e-mail]    osu-cis!chemabs!ddm26 |


Volume-Number: Volume 31, Number 98

From [e-mail]  Tue Jul  6 16:41:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06591; Tue, 6 Jul 93 16:41:10 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18254; Tue, 6 Jul 93 16:41:00 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14930; Tue, 6 Jul 93 13:40:57 PDT
Xref: majipoor.cygnus.com comp.std.unix:61
From: [e-mail] (Geoff Clare)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: UniSoft Ltd., London, England
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: errno pathconf strtod strtol strtoul
X-Submissions: [e-mail]
Date: 6 Jul 1993 13:24:22 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In <[e-mail]> [e-mail] (De Mickey) writes:
>However, the function return value can look valid (e.g.
>zero), so the application must set errno to zero before the
>call, and then test errno afterwards, if it wants to be sure
>the conversion was successful.

>    errno = 0;
>    dbl = strtod(ptr, &endptr);
>    if (errno != 0) {
>       /* complain to someone */
>    }

Although this example is probably safe, in general you should only ever
examine errno if the function return value indicates that it safe to
do so.  This is because POSIX allows functions to set errno to a non-zero
value when they succeed (the classic example is errno being set to ENOTTY
by stdio functions).

So in the case of pathconf(), which started this thread, instead of

    errno = 0;
    longval = pathconf(file, _PC_WHATEVER);
    if (errno != 0) {
       /* complain to someone */
    }

you should use

    errno = 0;
    longval = pathconf(file, _PC_WHATEVER);
    if (longval == -1 && errno != 0) {
       /* complain to someone */
    }

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


Volume-Number: Volume 31, Number 100

From [e-mail]  Tue Jul  6 16:41:11 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06592; Tue, 6 Jul 93 16:41:11 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18245; Tue, 6 Jul 93 16:40:58 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14924; Tue, 6 Jul 93 13:40:55 PDT
Xref: majipoor.cygnus.com comp.std.unix:60
From: [e-mail] (Bowyer Jeff)
Newsgroups: comp.std.unix
Subject: International Software
Organization: Technical University of Brno, Czech Republic
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Jul 1993 13:23:15 -0700
To: [e-mail]

Submitted-by: [e-mail] (Bowyer Jeff)

What UNIX standards are related to internationalization?  (I use Ultrix's
NLS features extensively, but I think they need serious improvement.)
Please share your insights with us.


INSOFT-L on [e-mail]   Internationalization of Software
                                    Discussion List

   Internationalization of software relates to two subjects:

        1. Software that is written so a user can easily change the
           language of the interface;

        2. Versions of software, such as Czech WordPerfect, whose
           interface language differs from the original product.

   Topics discussed on this list include:

        -- Techniques for developing new software

        -- Techniques for converting existing software

        -- Internationalization tools

        -- Announcements of internationalized public domain software

        -- Announcements of foreign-language versions of commercial
           software

        -- Calls for papers

    -- Conference announcements

    -- References to documentation related to the
           internationalization of software

   This list is moderated.

   To subscribe to this list, send an electronic mail message to
   [e-mail] with the body containing the command:

      SUB INSOFT-L Yourfirstname Yourlastname

   Owner:

      Center for Computing and Information Services
      Technical University of Brno
      Udolni 19, 602 00 BRNO
      Czech Republic

      [e-mail]



Volume-Number: Volume 31, Number 99