home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
volume.31
< prev
next >
Wrap
Internet Message Format
|
1993-07-15
|
358KB
From std-unix-request@uunet.UU.NET 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 <sef@uunet.uu.net>
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Message-Id: <1no38eINNo31@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2002
Date: 11 Mar 1993 11:17:34 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sef@uunet.uu.net (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
std-unix@uunet.uu.net, 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 std-unix@uunet.uu.net
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 std-unix@uunet.uu.net uunet!std-unix
Comments std-unix-request@uunet.uu.net 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., sef@kithrup.COM). 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
std-unix@uunet.uu.net, 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 std-unix@uunet.uu.net
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 std-unix@uunet.uu.net 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 <sws@calvin.wa.com> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <jsq@tic.com> 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 <stephe@mks.com>. Reports on other committees, such as X3J11,
are also included when available. These reports are published in
comp.std.unix/std-unix@uunet.uu.net 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 <domo@tsa.co.uk>,
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 std-unix@uunet.uu.net.
Volume-Number: Volume 31, Number 1
From std-unix-request@uunet.UU.NET 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 <rcollins@encore.com>
Newsgroups: comp.std.unix
Subject: Re: Conflict between .1 and .4a?
Organization: Encore Computer Corporation
Message-Id: <1no7m4INNjp@ftp.UU.NET>
References: <1nlfm6INN1ia@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2005
Date: 11 Mar 1993 12:33:08 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: rcollins@encore.com (Roger Collins)
wulkan@vnet.ibm.com (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 std-unix-request@uunet.UU.NET 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 <hlj@posix.com>
Newsgroups: comp.std.unix
Subject: Re: Posix.2
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <1no7ijINNee@ftp.UU.NET>
References: <1nlfduINN10l@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2004
Date: 11 Mar 1993 12:31:15 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: hlj@posix.COM (Hal Jespersen)
jsh@canary.com (Jeffrey S. Haemer) writes:
>David Rowley <david@mks.com> 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 std-unix-request@uunet.UU.NET 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 <sp@osf.org>
Newsgroups: comp.std.unix
Subject: Re: Conflict between .1 and .4a?
Organization: Open Software Foundation
Message-Id: <1no7olINNnr@ftp.UU.NET>
References: <1nlfm6INN1ia@ftp.UU.NET> <1nlfm6INN1ia@ftp.UU.NET>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2006
Date: 11 Mar 1993 12:34:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sp@osf.org (Simon Patience)
In article <1nlfm6INN1ia@ftp.UU.NET>, wulkan@vnet.ibm.com (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: +33-76-63-48-72
Research Institute FAX: +33-76-51-05-32
2 Avenue De Vignate Email: sp@gr.osf.org
38610 Gieres, France uunet!gr.osf.org!sp
Volume-Number: Volume 31, Number 5
From std-unix-request@uunet.UU.NET 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 <peter@ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Xenix Support, FICC
Message-Id: <1no7eqINN7f@ftp.UU.NET>
References: <1n4auaINNr3a@ftp.UU.NET> <1nja8cINNc45@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: test method
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2003
Date: 11 Mar 1993 12:29:14 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ferranti.com (peter da silva)
In article <1nja8cINNc45@ftp.UU.NET> jeffrey@netcom.com (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
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Volume-Number: Volume 31, Number 2
From std-unix-request@uunet.UU.NET 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 <rcollins@encore.com>
Newsgroups: comp.std.unix
Subject: POSIX .4 signals
Organization: Encore Computer Corporation
Message-Id: <1no7q3INNqs@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nlforINN1ol@ftp.UU.NET>
Reply-To: rcollins@encore.com
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2007
Date: 11 Mar 1993 12:35:15 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: rcollins@encore.com (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 std-unix-request@uunet.UU.NET 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 <jeffrey@netcom.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Message-Id: <1nr118INNpga@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nlforINN1ol@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2011
Date: 12 Mar 1993 13:58:00 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jeffrey@netcom.com (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.
jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087
Volume-Number: Volume 31, Number 10
From std-unix-request@uunet.UU.NET 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 <karish@pangea.Stanford.EDU>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Mindcraft, Inc.
Message-Id: <1nr0mmINNp22@ftp.UU.NET>
References: <1n4auaINNr3a@ftp.UU.NET> <1nja8cINNc45@ftp.UU.NET> <1no7eqINN7f@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: test method
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2009
Date: 12 Mar 1993 13:52:22 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
In article <1no7eqINN7f@ftp.UU.NET> peter@ferranti.com (peter da silva) writes:
>
>In article <1nja8cINNc45@ftp.UU.NET> jeffrey@netcom.com (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 karish@mindcraft.com
(415) 323-9000 x117 karish@pangea.stanford.edu
Volume-Number: Volume 31, Number 8
From std-unix-request@uunet.UU.NET 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 <peter@ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Xenix Support, FICC
Message-Id: <1nr0ggINNoqb@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nlforINN1ol@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2008
Date: 12 Mar 1993 13:49:04 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ferranti.com (peter da silva)
In article <1nlforINN1ol@ftp.UU.NET> bagwill@swe.ncsl.nist.gov (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
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Volume-Number: Volume 31, Number 7
From std-unix-request@uunet.UU.NET 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 <cotrozzi@dsi.unimi.it>
Newsgroups: comp.std.unix
Subject: What about .6
Organization: Computer Science Dep. - Milan University
Message-Id: <1nr0poINNp67@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Summary: How is .6 work going ?
Keywords: .6 security
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2010
Date: 12 Mar 1993 13:54:00 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: cotrozzi@dsi.unimi.it (Massimo Cotrozzi)
What is the status of 1003.6?
--
Massimo Cotrozzi Computer Science Dept. Milan Italy
cotrozzi@ghost.dsi.unimi.it +39-2-27201253
#include "std/disclaimer.h"
[ Wording changed slightly from Massimo's orignal -- mod ]
Volume-Number: Volume 31, Number 9
From std-unix-request@uunet.UU.NET 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 <henry@zoo.toronto.edu>
Newsgroups: comp.std.unix
Subject: perception of standards (was Even Good Test Method Standards...)
Organization: U of Toronto Zoology
Message-Id: <1ntrdhINNon4@ftp.UU.NET>
References: <1n4auaINNr3a@ftp.UU.NET> <1nja8cINNc45@ftp.UU.NET> <1no7eqINN7f@ftp.UU.NET> <1nr0mmINNp22@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2012
Date: 13 Mar 1993 15:40:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
In article <1nr0mmINNp22@ftp.UU.NET> karish@pangea.Stanford.EDU (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 bsdi-info@bsdi.com. 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. | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 31, Number 11
From std-unix-request@uunet.UU.NET 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: sethr@cbnewsl.att.com
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: AT&T Bell Laboratories
Message-Id: <1o2jroINN8pb@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nlforINN1ol@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2014
Date: 15 Mar 1993 11:02:16 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sethr@cbnewsl.att.com
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 std-unix-request@uunet.UU.NET 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 <rf@cl.cam.ac.uk>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: U of Cambridge Computer Lab, UK
Message-Id: <1o2jplINN8md@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nlforINN1ol@ftp.UU.NET> <1nr118INNpga@ftp.UU.NET> <1nr118INNpga@ftp.UU.NET>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2013
Date: 15 Mar 1993 11:01:09 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: rf@cl.cam.ac.uk (Robin Fairbairns)
In article <1nr118INNpga@ftp.UU.NET>, jeffrey@netcom.com (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 rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge CB2 3QG, UK
Volume-Number: Volume 31, Number 12
From std-unix-request@uunet.UU.NET 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 <dave@88open.org>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1o3a76INNmse@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nja8cINNc45@ftp.UU.NET>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2015
Date: 15 Mar 1993 17:23:50 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: dave@88open.org (Dave Cline)
In article <1nja8cINNc45@ftp.UU.NET>,
jeffrey@netcom.com (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 std-unix-request@uunet.UU.NET 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 <peter@ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Xenix Support, FICC
Message-Id: <1o3qdvINN158@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1no7eqINN7f@ftp.UU.NET> <1nr0mmINNp22@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: test method
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2016
Date: 15 Mar 1993 22:00:31 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ferranti.com (peter da silva)
In article <1nr0mmINNp22@ftp.UU.NET> karish@pangea.Stanford.EDU (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
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Volume-Number: Volume 31, Number 15
From std-unix-request@uunet.UU.NET 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 <amf@amfent.gwinnett.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1o5cavINNllc@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2017
Date: 16 Mar 1993 12:12:15 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: amf@amfent.gwinnett.com (Andy Feibus)
dave@88open.org (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
andyfe@utoday.com
Volume-Number: Volume 31, Number 16
From std-unix-request@uunet.UU.NET 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 <emery@goldfinger.mitre.org>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: The Mitre Corp., Bedford, MA.
Message-Id: <1o5t95INN2uo@ftp.UU.NET>
References: <1o5cavINNllc@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2018
Date: 16 Mar 1993 17:01:25 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: emery@goldfinger.mitre.org (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 std-unix-request@uunet.UU.NET 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 <wulkan@vnet.ibm.com>
Newsgroups: comp.std.unix
Subject: alarm()ing semantics
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1o7stuINNj6@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2019
Date: 17 Mar 1993 11:07:42 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: wulkan@vnet.IBM.COM (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 std-unix-request@uunet.UU.NET 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 <epstein@trwacs.fp.trw.com>
Newsgroups: comp.std.unix
Subject: POSIX security: call for participation
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1o87jaINN962@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2020
Date: 17 Mar 1993 14:09:46 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: epstein@trwacs.fp.trw.com (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 (410) 859-4463.
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 (202) 371-0101. The telephone number of the conference hotel
is (714) 553-0100.
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 std-unix-request@uunet.UU.NET 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 <karish@mindcraft.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1oan6pINNfpp@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2021
Date: 18 Mar 1993 12:48:25 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@mindcraft.com (Chuck Karish)
In Volume 31, Number 16, amf@amfent.gwinnett.com (Andy Feibus) wrote:
>dave@88open.org (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 karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 31, Number 20
From std-unix-request@uunet.UU.NET 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 <meulenbr@prl.philips.nl>
Newsgroups: comp.std.unix
Subject: controlling tty questions
Organization: Philips Research Laboratories Eindhoven, Netherlands
Message-Id: <1ojaj8INNrrl@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2022
Date: 21 Mar 1993 19:08:24 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@garth.kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: meulenbr@prl.philips.nl (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 (meulenbr@prl.philips.nl)
Philips Research Laboratories
Volume-Number: Volume 31, Number 21
From std-unix-request@uunet.UU.NET 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 <jeffrey@netcom.com>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Algorists, Inc.
Message-Id: <1ojaljINNrtb@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1o3a76INNmse@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2023
Date: 21 Mar 1993 19:09:39 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@garth.kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jeffrey@netcom.com (Jeffrey Kegler)
In article <1o3a76INNmse@ftp.UU.NET> dave@88open.org (Dave Cline) writes:
>In article <1nja8cINNc45@ftp.UU.NET>,
> jeffrey@netcom.com (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.
jeffrey@algor2.ALGORISTS.COM
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 std-unix-request@uunet.UU.NET 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 <lts@westford.ccur.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX .4 signals
Organization: Concurrent Computer Corp. Westford, MA
Message-Id: <1ol4trINNon6@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET> <1nlforINN1ol@ftp.UU.NET> <1no7q3INNqs@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2024
Date: 22 Mar 1993 11:43:55 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@garth.kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: lts@westford.ccur.com (Lee Schermerhorn)
>Submitted-by: rcollins@encore.com (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 std-unix-request@uunet.UU.NET 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 <peter@ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: controlling tty questions
Organization: Xenix Support, FICC
Message-Id: <1onos5INNhnl@ftp.UU.NET>
References: <1ojaj8INNrrl@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2025
Date: 23 Mar 1993 11:36:37 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@garth.kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ferranti.com (peter da silva)
In article <1ojaj8INNrrl@ftp.UU.NET> meulenbr@prl.philips.nl (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
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Volume-Number: Volume 31, Number 24
From std-unix-request@uunet.UU.NET 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" <preece@urbana.mcd.mot.com>
Newsgroups: comp.std.unix
Subject: Work on a uniform API for GUI programming
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1oqhinINNrve@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2028
Date: 24 Mar 1993 12:50:31 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@garth.kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: preece@urbana.mcd.mot.com (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 202-371-0101); 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: preece@urbana.mcd.mot.com
Telephone: 217-384-8589
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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Algorists, Inc.
Sender: sef@ftp.uu.net
Message-Id: <1ovqhcINNseh@ftp.UU.NET>
References: <1ojaljINNrtb@ftp.UU.NET> <1oqhg1INNrs4@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2029
Date: 26 Mar 1993 12:54:04 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jeffrey@netcom.com (Jeffrey Kegler)
In article <1oqhg1INNrs4@ftp.UU.NET> dave@88open.org (Dave Cline) writes:
>In article <1ojaljINNrtb@ftp.UU.NET>,
> jeffrey@netcom.com (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.
jeffrey@algor2.ALGORISTS.COM
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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
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: sef@ftp.uu.net
Distribution: inet
Message-Id: <1p2h2qINNb29@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 Mar 1993 13:31:06 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: david@twg.com ("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 <david@twg.com> (work) <david@davids.mmdf.com> (home)
[ Note crossposting, and followup -- mod ]
Volume-Number: Volume 31, Number 29
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1palcaINNglb@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 30 Mar 1993 15:33:30 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: dave@88open.org (Dave Cline)
[ A surprise! An article that actually mentions a standard or two! -- mod ]
>In article <1ovqhcINNseh@ftp.UU.NET>
> jeffrey@netcom.com (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 dave@88open.org
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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Electronic Balloting
Organization: Colorado SuperNet, Inc.
Sender: sef@ftp.uu.net
Message-Id: <1pqcb6INN659@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Apr 1993 15:37:26 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@teal.csn.org (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 <jsh@usenix.org>
- Pat Wilson, SAGE Board Member <paw@rigel.dartmouth.edu>
Volume-Number: Volume 31, Number 31
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Request for Technology
Organization: X/Open Company Ltd
Sender: sef@ftp.uu.net
Message-Id: <1pseoqINN2uk@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 Apr 1993 10:31:05 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: james@xopen.co.uk (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: j.andrews@xopen.co.uk Reading, England, RG1 1AX
Tel: +(44) (0)734 508311 FAX: +(44) (0)734 500110
Volume-Number: Volume 31, Number 32
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: Electronic Balloting
Organization: Data General Corporation
Sender: sef@ftp.uu.net
Message-Id: <1q4o47INN8fb@ftp.UU.NET>
References: <1pqcb6INN659@ftp.UU.NET> <1pqcb6INN659@ftp.UU.NET>
Reply-To: lewine@cheshirecat.webo.dg.com
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 Apr 1993 13:59:51 -0700
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)
In article <1pqcb6INN659@ftp.UU.NET>, jsh@teal.csn.org (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 (508) 870-9008 Voice
Data General Corporation (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580 U.S.A.
uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
Volume-Number: Volume 31, Number 33
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Posix.9 report
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1q5no4INNo13@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 Apr 1993 22:59:32 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: nick@santec.boston.ma.us (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 <mjhanna@sandia.gov>, 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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: POSIX status
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1qk87qINN3ld@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 1993 11:06:50 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: lorrain@mtuxo.att.com
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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Quarterly report
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1qk8abINN3or@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 1993 11:08:11 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: lorrain@mtuxo.att.com
____________________________________________________________________
PASC SEC SD11
subject: Balloting Vice-Chair Status date: April 14, 1993
Report - 2nd Quarter 1993
from: L. C. Kevra
908-234-6423
l.kevra@att.com
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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: expr questions
Organization: Kaleida Labs, Inc., Mountain View, CA
Sender: sef@ftp.uu.net
Message-Id: <1qk8cuINN3ro@ftp.UU.NET>
Reply-To: jtc@wimsey.com
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 1993 11:09:34 -0700
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: conklin@kaleida.com (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 <jtc@wimsey.com> | 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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: expr questions
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1qn3faINNki1@ftp.UU.NET>
References: <1qk8cuINN3ro@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Apr 1993 13:03:54 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@mindcraft.com (Chuck Karish)
conklin@kaleida.com (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 karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 31, Number 38
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: Job Control and POSIX
Organization: Motorola Computer Group, Urbana Design Center
Sender: sef@ftp.uu.net
Message-Id: <1r77ojINN85n@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 22 Apr 1993 15:55:15 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
This is in reply to a posting on 25 Feb by salevin@dal.mobile.com.
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: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 31, Number 40
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: POSIX.2: what should 'printf "%c" 3' print?
Organization: Project GLUE, University of Maryland
Sender: sef@ftp.uu.net
Message-Id: <1r77kaINN83e@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 22 Apr 1993 15:52:58 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: djm@eng.umd.edu (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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Prsentation on "Standards for Unix" - Help
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1rjrqkINNicu@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 Apr 1993 10:51:16 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jacob@teslab.lab.oz.au (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: jacob@teslab.lab.oz.au
phone: (02) 287 6676 level 4 121 Macquarie Street
fax: (02) 287 6791 Sydney 2000.
Volume-Number: Volume 31, Number 42
From std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: POSIX.2: what should 'printf "%c" 3' print?
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: sef@ftp.uu.net
Message-Id: <1rjrlgINNi92@ftp.UU.NET>
References: <1r77kaINN83e@ftp.UU.NET> <1r77kaINN83e@ftp.UU.NET>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 Apr 1993 10:48:32 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
In article <1r77kaINN83e@ftp.UU.NET>, djm@eng.umd.edu (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 std-unix-request@uunet.UU.NET 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: std-unix-request@uunet.uu.net
Newsgroups: comp.std.unix
Subject: Re: Prsentation on "Standards for Unix" - Help
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1rk8t7INNr3o@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 Apr 1993 14:34:31 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: POSIX Guide
Organization: USENIX
Sender: sef@ftp.uu.net
Message-Id: <1rp44dINNp95@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Apr 1993 10:43:41 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.0: POSIX Guide
Kevin Lewis <klewis@gucci.ent.dec.com> 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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.4: Real Time
Organization: USENIX
Sender: sef@ftp.uu.net
Message-Id: <1rp4fqINNpke@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Apr 1993 10:49:46 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.4: Real Time
Bill O. Gallmeister <bog@lynx.com>, 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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.18: POSIX Platform Environment Profile
Organization: USENIX
Sender: sef@ftp.uu.net
Message-Id: <1rp48vINNpdv@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Apr 1993 10:46:07 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.18: POSIX Platform Environment Profile
Paul Borman <prb@cray.com> 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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: USENIX
Sender: sef@ftp.uu.net
Message-Id: <1rp4ccINNphb@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Apr 1993 10:47:56 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.19: FORTRAN-90 Bindings
Michael J. Hannah <mjhannah@sandia.gov>, 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 std-unix-request@uunet.UU.NET 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!davidm@uunet.UU.NET (David S. Masterson)
Newsgroups: comp.std.unix
Subject: Re: POSIX.2: what should 'printf "%c" 3' print?
Organization: Consilium Inc., Mountain View, California
Sender: sef@ftp.uu.net
Message-Id: <1rro2qINNk3f@ftp.UU.NET>
References: <1r77kaINN83e@ftp.UU.NET> <1r77kaINN83e@ftp.UU.NET>, <1rjrlgINNi92@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 30 Apr 1993 10:36:26 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: davidm@cimshop.UUCP (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.
(415) 691-6311 640 Clyde Ct.
davidm@consilium.com Mtn. View, CA 94043
Volume-Number: Volume 31, Number 48
From std-unix-request@uunet.UU.NET 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: d@exnet.co.uk (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: sef@ftp.uu.net
Message-Id: <1s3sf1INNbuj@ftp.UU.NET>
References: <1r77kaINN83e@ftp.UU.NET> <1rjrlgINNi92@ftp.UU.NET> <1rro2qINNk3f@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 May 1993 12:40:17 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: d@exnet.co.uk (Damon)
In article <1rro2qINNk3f@ftp.UU.NET> davidm@cimshop.UUCP (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 d@hd.org London UK
Tel/Fax: +44 81 755 0077======Two jobs:
(1) Parallelogram Editor, [1.42]
(2) Seller of public-access news/mail & cheap Suns (mail info@exnet.co.uk).
Volume-Number: Volume 31, Number 49
From std-unix-request@uunet.UU.NET 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: ok@goanna.cs.rmit.oz.au (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: sef@ftp.uu.net
Message-Id: <1s3shfINNc1t@ftp.UU.NET>
References: <1r77kaINN83e@ftp.UU.NET> <1r77kaINN83e@ftp.UU.NET>, <1rro2qINNk3f@ftp.UU.NET> <1rro2qINNk3f@ftp.UU.NET>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 May 1993 12:41:35 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
In article <1rro2qINNk3f@ftp.UU.NET>, davidm@cimshop.UUCP (David S. Masterson) writes:
> Submitted-by: davidm@cimshop.UUCP (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 std-unix-request@uunet.UU.NET 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: pma@rutherford.ac.uk (Peter Allan)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: Rutherford Appleton Laboratory
Sender: sef@ftp.uu.net
Message-Id: <1s6v0bINN9ei@ftp.UU.NET>
References: <1rp4ccINNphb@ftp.UU.NET>
Reply-To: pma@rutherford.ac.uk (Peter Allan)
X-Submissions: std-unix@uunet.uu.net
Date: 4 May 1993 16:42:03 -0700
To: std-unix@uunet.UU.NET
Submitted-by: pma@rutherford.ac.uk (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 std-unix-request@uunet.UU.NET 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: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.19: FORTRAN-90 Bindings
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1s8s33INNkus@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 May 1993 10:04:35 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (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 std-unix-request@uunet.UU.NET 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: wulkan@vnet.IBM.COM (Mike Wulkan)
Newsgroups: comp.std.unix
Subject: Confusing abort() semantics
Organization: Kithrup Enterprises, Ltd.
Sender: sef@ftp.uu.net
Message-Id: <1s8s8bINNl4h@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 May 1993 10:07:23 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: wulkan@vnet.IBM.COM (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 std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (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: sef@ftp.uu.net
Message-Id: <1sd4rqINN53e@ftp.UU.NET>
References: <1rp4ccINNphb@ftp.UU.NET> <1s6v0bINN9ei@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 7 May 1993 00:58:50 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1s6v0bINN9ei@ftp.UU.NET> pma@rutherford.ac.uk (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 std-unix-request@uunet.UU.NET 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: eposnak@dale.ksc.nasa.gov (Ed Posnak)
Newsgroups: comp.std.unix
Subject: POSIX.4 Semaphores
Organization: NASA
Sender: sef@ftp.uu.net
Message-Id: <1sd4qkINN51r@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 7 May 1993 00:58:12 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: eposnak@dale.ksc.nasa.gov (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
eposnak%core1@kssib.ksc.nasa.gov
Volume-Number: Volume 31, Number 55
From std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Confusing abort() semantics
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@ftp.uu.net
Message-Id: <1sd4p9INN500@ftp.UU.NET>
References: <1s8s8bINNl4h@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 7 May 1993 00:57:29 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1s8s8bINNl4h@ftp.UU.NET> wulkan@vnet.IBM.COM (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 Gwyn@ARL.Army.Mil
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 std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: oops (was: Confusing abort() semantics)
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: sef@ftp.uu.net
Message-Id: <1se6cmINNjgk@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: abort
X-Submissions: std-unix@uunet.uu.net
Date: 7 May 1993 10:31:02 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (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 Gwyn@ARL.Army.Mil
---
> last edit: 07-May-1993 Gwyn@ARL.Army.Mil
73c73
< sigfunc == SIG_DFL;
---
> sigfunc = SIG_DFL; /* bug fix courtesy rlh@world.std.com */
Sorry about that..
Volume-Number: Volume 31, Number 57
From std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Confusing abort() semantics
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: sef@rodan.uu.net
Message-Id: <1smom1INNoa5@rodan.UU.NET>
References: <1s8s8bINNl4h@ftp.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 10 May 1993 16:32:17 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (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 std-unix-request@uunet.UU.NET 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: mnielsen@stdsmail.ieee.org ("M.Nielsen")
Newsgroups: comp.std.unix
Subject: POSIX Open Order Plan
Organization: Kithrup Enterprises, Ltd.
Sender: sef@rodan.uu.net
Message-Id: <1smoi9INNo63@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 10 May 1993 16:30:17 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mnielsen@stdsmail.ieee.org ("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 (908) 981-5432. 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 (908) 562-9667
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 std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: oops (was: Confusing abort() semantics)
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: sef@rodan.uu.net
Message-Id: <1sq0hmINN91r@rodan.UU.NET>
References: <1se6cmINNjgk@ftp.UU.NET>
Nntp-Posting-Host: rodan.uu.net
Keywords: abort
X-Submissions: std-unix@uunet.uu.net
Date: 11 May 1993 22:04:54 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
Ok, here is the latest improvement to the abort() implementation I posted
earlier in this thread:
6c6
< last edit: 07-May-1993 Gwyn@ARL.Army.Mil
---
> last edit: 11-May-1993 Gwyn@ARL.Army.Mil
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 wulkan@vnet.ibm.com */
> else
> #endif
Volume-Number: Volume 31, Number 60
From std-unix-request@uunet.UU.NET 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: peter@nmti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: POSIX 1003.4 questions
Organization: Network/development platform support, NMTI
Sender: sef@rodan.uu.net
Message-Id: <1stvpmINNofe@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 May 1993 10:16:38 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: peter@nmti.com (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
+1 713 274 5180 "Na sema Jambo mbwa kali yake leo?"
Volume-Number: Volume 31, Number 61
From std-unix-request@uunet.UU.NET 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: bitbug@netcom.com (James Buster)
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.4 questions
Organization: Lynx Real-Time Systems, Inc.
Sender: sef@rodan.uu.net
Message-Id: <1suta6INNd65@rodan.UU.NET>
References: <1stvpmINNofe@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 May 1993 18:40:22 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: bitbug@netcom.com (James Buster)
In article <1stvpmINNofe@rodan.UU.NET> peter@nmti.com (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
bitbug@netcom.com
Volume-Number: Volume 31, Number 63
From std-unix-request@uunet.UU.NET 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: peter@nmti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: POSIX 1003.4 conflict?
Organization: Network Management Technology, Incorporated
Sender: sef@rodan.uu.net
Message-Id: <1sut8kINNd3m@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 May 1993 18:39:32 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: peter@nmti.com (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
+1 713 274 5180 "Na sema Jambo mbwa kali yake leo?"
Volume-Number: Volume 31, Number 62
From std-unix-request@uunet.UU.NET 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: willcox@urbana.mcd.mot.com (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.4 questions
Organization: Motorola Computer Group, Urbana Design Center
Sender: sef@rodan.uu.net
Message-Id: <1t64enINN1jk@rodan.UU.NET>
References: <1stvpmINNofe@rodan.UU.NET> <1suta6INNd65@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 May 1993 12:25:11 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
bitbug@netcom.com (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: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 31, Number 64
From std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.4 questions
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@rodan.uu.net
Message-Id: <1t64gjINN1ld@rodan.UU.NET>
References: <1stvpmINNofe@rodan.UU.NET> <1suta6INNd65@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 May 1993 12:26:11 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1suta6INNd65@rodan.UU.NET> bitbug@netcom.com (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 std-unix-request@uunet.UU.NET 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" <mnielsen@stdsmail.ieee.org>
Newsgroups: comp.std.unix,comp.std.internat,comp.std.misc
Subject: Correction
Followup-To: comp.std.misc
Organization: Kithrup Enterprises, Ltd.
Sender: sef@rodan.uu.net
Message-Id: <1t64puINN1s6@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 May 1993 12:31:10 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jsh@canary.com (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 (908) 562-5432. 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 (908) 562-9667
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 std-unix-request@uunet.UU.NET 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: peter@nmti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: P1003.4a, pthread_key_create, typo?
Organization: Network/development platform support, NMTI
Sender: sef@rodan.uu.net
Message-Id: <1t64t0INN1u6@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 May 1993 12:32:48 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: peter@nmti.com (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
+1 713 274 5180 "Na sema Jambo mbwa kali yake leo?"
Volume-Number: Volume 31, Number 67
From std-unix-request@uunet.UU.NET 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: baker@omicron.cs.fsu.edu (Ted Baker)
Newsgroups: comp.std.unix
Subject: POSIX Real-Time Ada bindings ballot
Organization: Florida State University Computer Science Department
Sender: sef@rodan.uu.net
Message-Id: <1tgfauINNt64@rodan.UU.NET>
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: std-unix@uunet.uu.net
Date: 20 May 1993 10:32:14 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: baker@omicron.cs.fsu.edu (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: 908/562-1571
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 (908) 981-1398 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: 303/792-2192 FAX: 212/302-1286
---------------------------------------------------------------------------
Volume-Number: Volume 31, Number 68
From std-unix-request@uunet.UU.NET 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: WANISH@KGNVMC.VNET.IBM.COM ("Paul J. Wanish ((914)385-0217)")
Newsgroups: comp.std.unix
Subject: POSIX.1 PAR for Splitting 9945-1
Organization: Kithrup Enterprises, Ltd.
Sender: sef@rodan.uu.net
Message-Id: <1ttr4kINNdc1@rodan.UU.NET>
Reply-To: wanish@kgnvmc.VNET.IBM.COM
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 25 May 1993 12:13:24 -0700
To: std-unix@uunet.UU.NET
Submitted-by: WANISH@KGNVMC.VNET.IBM.COM ("Paul J. Wanish ((914)385-0217)")
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 std-unix-request@uunet.UU.NET 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: djb@silverton.berkeley.edu (D. J. Bernstein)
Newsgroups: comp.std.unix
Subject: Re: POSIX Open Order Plan
Organization: IR
Sender: sef@rodan.uu.net
Message-Id: <1tv097INNng8@rodan.UU.NET>
References: <1smoi9INNo63@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 25 May 1993 22:47:19 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: djb@silverton.berkeley.edu (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 std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (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: sef@rodan.uu.net
Message-Id: <1u6us7INNq15@rodan.UU.NET>
References: <1ttr4kINNdc1@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 May 1993 23:12:23 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1ttr4kINNdc1@rodan.UU.NET> wanish@kgnvmc.VNET.IBM.COM 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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE Standards Board
Organization: USENIX Standards Report Editor
Sender: sef@rodan.uu.net
Message-Id: <1u6uu0INNqal@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 May 1993 23:13:20 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
IEEE Standards Board
Mary Lynne Nielsen <m.nielsen@ieee.org> 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 j.iorio@ieee.org.
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 std-unix-request@uunet.UU.NET 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: markmc@halcyon.halcyon.com (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: sef@rodan.uu.net
Message-Id: <1u92iiINN21u@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 May 1993 18:27:46 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: markmc@halcyon.halcyon.com (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 +1 206 632 1905 (voice)
markmc@halcyon.com Box 31356, Seattle WA 98103-1356 +1 206 632 1738 (fax)
[ Note cross-posting, and followup, please -- mod ]
Volume-Number: Volume 31, Number 73
From std-unix-request@uunet.UU.NET 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: jsh@teal.csn.org (Jeffrey Haemer)
Newsgroups: comp.std.unix
Subject: Electronic Balloting
Organization: Colorado SuperNet, Inc.
Sender: sef@rodan.uu.net
Message-Id: <1uoeafINN1i2@rodan.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Date: 4 Jun 1993 14:20:15 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jsh@teal.csn.org (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 <jsh@usenix.org>
Pat Wilson, SAGE Board Member <paw@rigel.dartmouth.edu>
========
#! /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 ballot@canary.com 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<posix-dot-fifty@canary.com>).
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 <jsh@usenix.org>
X- Pat Wilson, SAGE Board Member <paw@rigel.dartmouth.edu>
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 std-unix-request@uunet.UU.NET 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: sean@netcom.com (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: <1uop2eINNg2a@darkstar.UCSC.EDU>
Nntp-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp
Date: 5 Jun 1993 00:23:42 GMT
Apparently-To: <std-unix-archive@uunet.uu.net>
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 sean@netcom.com
From std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, \*(Rh
Organization: USENIX Standards Report Editor
Sender: sef@rodan.uu.net
Message-Id: <1vqdh5INNhk8@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 17 Jun 1993 11:35:16 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.5: Ada Bindings
Organization: USENIX Standards Report Editor
Sender: sef@rodan.uu.net
Message-Id: <1vqdeiINNhde@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 17 Jun 1993 11:33:54 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.5: Ada Bindings
Del Swanson <dswanson@email.sp.paramax.com> 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 std-unix-request@uunet.UU.NET 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: duke@iscp.bellcore.com (Duke Robillard)
Newsgroups: comp.std.unix
Subject: Standards Update, \*(Rh
Organization: Kithrup Enterprises, Ltd.
Sender: sef@rodan.uu.net
Message-Id: <1vt1nbINNhq4@rodan.UU.NET>
Reply-To: duke@iscp.bellcore.com
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 18 Jun 1993 11:32:11 -0700
To: std-unix@uunet.UU.NET
Submitted-by: duke@iscp.bellcore.com (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 std-unix-request@uunet.UU.NET 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: lwv26@cas.org (Larry W. Virden)
Newsgroups: comp.std.unix
Subject: P1003.2 and the grep command
Organization: Nedriv Software and Shoe Shiners, Uninc.
Sender: sef@rodan.uu.net
Message-Id: <207f29INNge@rodan.UU.NET>
Reply-To: lvirden@cas.org
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 22 Jun 1993 10:21:13 -0700
To: std-unix@uunet.UU.NET
Submitted-by: lwv26@cas.org (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: lvirden@cas.org
:s Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
Volume-Number: Volume 31, Number 78
From std-unix-request@uunet.UU.NET 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: mike@pdx095.intel.com (Mike Haertel)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: MD6
Sender: sef@rodan.uu.net
Message-Id: <20859nINN6dj@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 22 Jun 1993 16:40:39 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mike@pdx095.intel.com (Mike Haertel)
In article <207f29INNge@rodan.UU.NET> lwv26@cas.org (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 <mike@ichips.intel.com>
This is a private posting; it does not indicate opinions or positions
of Intel Corp.
Volume-Number: Volume 31, Number 80
From std-unix-request@uunet.UU.NET 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: steve@amber.ssd.csd.harris.com (Steve Brosky)
Newsgroups: comp.std.unix
Subject: Posix.4, accepted?
Organization: Harris CSD, Ft. Lauderdale, FL
Sender: sef@rodan.uu.net
Message-Id: <208588INN68v@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 22 Jun 1993 16:39:52 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: steve@amber.ssd.csd.harris.com (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 std-unix-request@uunet.UU.NET 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: berg@pool.informatik.rwth-aachen.de (Stephen R. van den Berg)
Newsgroups: comp.std.unix
Subject: setgid() and saved gids, why made impossible?
Organization: Rechnerbetrieb Informatik - RWTH Aachen
Sender: sef@rodan.uu.net
Message-Id: <20a3ilINNfv8@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 23 Jun 1993 10:23:33 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: berg@pool.informatik.rwth-aachen.de (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, berg@pool.informatik.rwth-aachen.de
Stephen R. van den Berg (AKA BuGless). berg@physik.tu-muenchen.de
I've never been superstitious! Knock on wood.
Volume-Number: Volume 31, Number 82
From std-unix-request@uunet.UU.NET 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: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: FOO
Sender: sef@rodan.uu.net
Message-Id: <20a3eqINNfog@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 23 Jun 1993 10:21:30 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
In article <20859nINN6dj@rodan.UU.NET> mike@pdx095.intel.com (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.
--
+1 617 628 6197 (H) | Offer to God a sacrifice of thanksgiving
+1 617 253 8568 (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 std-unix-request@uunet.UU.NET 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: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: FWI, University of Amsterdam
Sender: sef@rodan.uu.net
Message-Id: <20ac9sINN3eb@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET> <20a3eqINNfog@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 23 Jun 1993 12:52:28 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: casper@fwi.uva.nl (Casper H.S. Dik)
mib@churchy.gnu.ai.mit.edu (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 std-unix-request@uunet.UU.NET 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: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: FOO
Sender: sef@rodan.uu.net
Message-Id: <20dg5pINNruv@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET> <20ac9sINN3eb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 24 Jun 1993 17:16:57 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <20ac9sINN3eb@rodan.UU.NET> casper@fwi.uva.nl (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.
--
+1 617 628 6197 (H) | Offer to God a sacrifice of thanksgiving
+1 617 253 8568 (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 std-unix-request@uunet.UU.NET 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: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: HaL Computer Systems
Sender: sef@rodan.uu.net
Message-Id: <20dgdfINNs6n@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Date: 24 Jun 1993 17:21:03 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (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.
mib@churchy.gnu.ai.mit.edu (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.
casper@fwi.uva.nl (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 std-unix-request@uunet.UU.NET 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: guy@auspex.com (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: Auspex Systems, Santa Clara
Sender: sef@rodan.uu.net
Message-Id: <20isj2INN32o@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET> <20dgdfINNs6n@rodan.uu.net>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 26 Jun 1993 18:19:30 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: guy@auspex.com (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 std-unix-request@uunet.UU.NET 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: lwv26@cas.org (Larry W. Virden)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: Nedriv Software and Shoe Shiners, Uninc.
Sender: sef@rodan.uu.net
Message-Id: <20iskbINN34t@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET> <20dgdfINNs6n@rodan.uu.net>
Reply-To: lvirden@cas.org
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 26 Jun 1993 18:20:11 -0700
To: std-unix@uunet.UU.NET
Submitted-by: lwv26@cas.org (Larry W. Virden)
In <20dgdfINNs6n@rodan.uu.net> Jason Zions <jazz@hal.com> 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: lvirden@cas.org
:s Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
Volume-Number: Volume 31, Number 87
From std-unix-request@uunet.UU.NET 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: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: HaL Computer Systems
Sender: sef@rodan.uu.net
Message-Id: <20norfINN2f0@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET> <20isj2INN32o@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 Jun 1993 14:46:23 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
In article <20isj2INN32o@rodan.UU.NET> guy@auspex.com (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 std-unix-request@uunet.UU.NET 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: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: HaL Computer Systems
Sender: sef@rodan.uu.net
Message-Id: <20notfINN2in@rodan.UU.NET>
References: <207f29INNge@rodan.UU.NET> <20859nINN6dj@rodan.UU.NET> <20iskbINN34t@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 Jun 1993 14:47:27 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
In article <20iskbINN34t@rodan.UU.NET> lwv26@cas.org (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 std-unix-request@uunet.UU.NET 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: ghica@fig.citib.com (Renato Ghica)
Newsgroups: comp.std.unix
Subject: POSIX sources
Organization: Citibank IBISM
Sender: sef@rodan.uu.net
Message-Id: <20nouoINN2kr@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 Jun 1993 14:48:08 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: ghica@fig.citib.com (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 std-unix-request@uunet.UU.NET 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: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: P1003.2 and the grep command
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@rodan.uu.net
Message-Id: <20novqINN2oh@rodan.UU.NET>
References: <20859nINN6dj@rodan.UU.NET> <20a3eqINNfog@rodan.UU.NET> <20ac9sINN3eb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 Jun 1993 14:48:42 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <20ac9sINN3eb@rodan.UU.NET> casper@fwi.uva.nl (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 std-unix-request@uunet.UU.NET 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: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.22: POSIX Security Framework
Organization: USENIX Standards Report Editor
Sender: sef@rodan.uu.net
Message-Id: <20q408INNlqf@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Jun 1993 12:08:56 -0700
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.22: POSIX Security Framework
David Rogers <drogers@datlog.co.uk> 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 std-unix-request@uunet.UU.NET 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: ericb@sierra.com (Eric Blood)
Newsgroups: comp.std.unix
Subject: pathconf()/errno question
Organization: Sierra Geophysics Inc., Kirkland, Wa
Sender: sef@rodan.uu.net
Message-Id: <20t4bcINN5jb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 30 Jun 1993 15:33:16 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: ericb@sierra.com (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
ericb@sierra.com
Volume-Number: Volume 31, Number 93
From std-unix-request@uunet.UU.NET 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: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: FOO
Sender: sef@rodan.uu.net
Message-Id: <20tr6eINNb9q@rodan.UU.NET>
References: <20t4bcINN5jb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 30 Jun 1993 22:03:10 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <20t4bcINN5jb@rodan.UU.NET> ericb@sierra.com (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
--
+1 617 628 6197 (H) | Offer to God a sacrifice of thanksgiving
+1 617 253 8568 (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 std-unix-request@uunet.UU.NET 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: durst@mwunix.mitre.org (Robert Durst)
Newsgroups: comp.std.unix
Subject: POSIX Ballot pool forming for Sockets and XTI
Organization: The MITRE Corporation
Sender: sef@rodan.uu.net
Message-Id: <2103vhINNk8c@rodan.UU.NET>
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: std-unix@uunet.uu.net
Date: 1 Jul 1993 18:45:21 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: durst@mwunix.mitre.org (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
durst@mitre.org
Volume-Number: Volume 31, Number 96
From std-unix-request@uunet.UU.NET 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: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: Kithrup Enterprises, Ltd.
Sender: sef@rodan.uu.net
Message-Id: <2103ttINNk68@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 1 Jul 1993 18:44:29 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
From mib@geech.gnu.ai.mit.edu (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 karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 31, Number 95
From std-unix-request@uunet.UU.NET 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: willcox@urbana.mcd.mot.com (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: Motorola Computer Group, Urbana Design Center
Sender: sef@rodan.uu.net
Message-Id: <211sk1INNj74@rodan.UU.NET>
References: <2103ttINNk68@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Jul 1993 10:52:01 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
karish@mindcraft.com (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: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 31, Number 97
From std-unix-request@uunet.UU.NET 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: ddm26@cas.org (De Mickey)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: Chemical Abstracts Service, Columbus, Ohio
Sender: sef@rodan.uu.net
Message-Id: <212aaeINNl49@rodan.UU.NET>
References: <2103ttINNk68@rodan.UU.NET> <211sk1INNj74@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
Summary: ANSI C requires a writable errno as well
Keywords: errno pathconf strtod strtol strtoul
X-Submissions: std-unix@uunet.uu.net
Date: 2 Jul 1993 14:45:50 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: ddm26@cas.org (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 |
ddm26@cas.org osu-cis!chemabs!ddm26 |
Volume-Number: Volume 31, Number 98
From std-unix-request@uunet.UU.NET 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: gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.std.unix
Subject: Re: pathconf()/errno question
Organization: UniSoft Ltd., London, England
Sender: sef@rodan.uu.net
Message-Id: <21cn1mINN4a1@rodan.UU.NET>
References: <2103ttINNk68@rodan.UU.NET> <211sk1INNj74@rodan.UU.NET> <212aaeINNl49@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
Keywords: errno pathconf strtod strtol strtoul
X-Submissions: std-unix@uunet.uu.net
Date: 6 Jul 1993 13:24:22 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwc@root.co.uk (Geoff Clare)
In <212aaeINNl49@rodan.UU.NET> ddm26@cas.org (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 <gwc@root.co.uk> (USA antiquated mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273
Volume-Number: Volume 31, Number 100
From std-unix-request@uunet.UU.NET 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: jbowyer@cis.vutbr.cz (Bowyer Jeff)
Newsgroups: comp.std.unix
Subject: International Software
Organization: Technical University of Brno, Czech Republic
Sender: sef@rodan.uu.net
Message-Id: <21cmvjINN46v@rodan.UU.NET>
Reply-To: jbowyer@cis.vutbr.cz
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 Jul 1993 13:23:15 -0700
To: std-unix@uunet.UU.NET
Submitted-by: jbowyer@cis.vutbr.cz (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 LISTSERV@CIS.VUTBR.CZ 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
LISTSERV@CIS.VUTBR.CZ 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
INSOFT-L-REQUEST@CIS.VUTBR.CZ
Volume-Number: Volume 31, Number 99