Article View: comp.std.unix
Article #952Re: POSIX question: dynamic linking
From: Chesley Reyburn
Date: Thu, 20 Feb 1992 17:47
Date: Thu, 20 Feb 1992 17:47
10192 lines
436037 bytes
436037 bytes
Submitted-by: cmr@cvedc.prime.com (Chesley Reyburn)
barmar@think.com (Barry Margolin) writes:
>What about the kind of stuff that one needs dlopen() for, i.e. where a
>runtime-specified module must be linked in? That's a source-level view.
Thank you! I sent mail yesterday to Mr. Lewine stating the same
thing and proposing something like:
void *(*local_func())(char *filename, char *entryname)
Where local_func() is part of POSIX. Filename is a fully qualified
file name where the source code that describes the function may be found.
Entryname describes the entry point in the object.
The only problem that I can see is that the above function
limits the new functions to always only returning a pointer
to void. Perhaps an additional argument describing the type
of return value?
Chesley Reyburn cmr@cvedc.prime.com
ECAE Software, Prime Computer, Inc. Phone: 503/645-2410
14952 NW Greenbrier Parkway Beaverton, OR 97006-5733, USA
Volume-Number: Volume 27, Number 2
From std-unix-request@uunet.UU.NET Sat Feb 22 18:44:14 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA25673; Sat, 22 Feb 92 18:44:14 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA25730; Sat, 22 Feb 92 18:44:12 -0500
Newsgroups: comp.std.unix
From: Barry Margolin <barmar@think.com>
Subject: Re: POSIX question: dynamic linking
Message-Id: <1992Feb22.232922.16009@uunet.uu.net>
Originator: sef@ftp.UU.NET
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <1992Feb18.204251.3356@uunet.uu.net> <1992Feb19.202414.8126@uunet.uu.net> <1992Feb22.073646.18830@uunet.uu.net>
Date: Sat, 22 Feb 1992 16:21:30 GMT
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: barmar@think.com (Barry Margolin)
In article <1992Feb22.073646.18830@uunet.uu.net> cmr@cvedc.prime.com (Chesley Reyburn) writes:
>Thank you! I sent mail yesterday to Mr. Lewine stating the same
>thing and proposing something like:
>
> void *(*local_func())(char *filename, char *entryname)
...
>The only problem that I can see is that the above function
>limits the new functions to always only returning a pointer
>to void.
I don't think that's a problem. The caller should be required to cast the
returned pointer to the actual type of the function that is being linked
in. So, if you're trying to dynamically load a function that returns an
int, you would write:
int (*foo_fun)();
foo_fun = (int (*)()) local_func(filename, entryname);
BTW, why did you specify void* in the first place? Since the default
return type in C is int, it would probably be more intuitive for
local_func() to return an int function rather than a void* function.
Another reasonable default would be a void function. But either way, the
caller will have to cast it if the default isn't appropriate for that
function.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
Volume-Number: Volume 27, Number 4
From std-unix-request@uunet.UU.NET Sat Feb 22 18:44:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA25688; Sat, 22 Feb 92 18:44:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA25740; Sat, 22 Feb 92 18:44:16 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <karish@mindcraft.com>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb22.232957.16129@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Feb22.073722.18969@uunet.uu.net>
Date: Sat, 22 Feb 1992 17:28:17 GMT
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 article <1992Feb22.073722.18969@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM
(Mike Wulkan) writes:
>Submitted-by: WULKAN@TOROLAB6.VNET.IBM.COM (Mike Wulkan)
>I have a question as to the intent of the following statement in section
>3.3.1.3 of 1003.1:
>
> 521 (c) The behavior of a process is undefined after it returns normally
> 522 from a signal-catching function for a SIGFPE, SIGILL, or SIGSEGV
> 523 signal that was not generated by the kill() function or the raise()
> 524 function defined by the C Standard {2}.
>
>Is the intent of Posix to "limit" the scope of "other
>implementation-defined value" to exactly SIGFPE, SIGILL and SIGSEGV?
>
>Or is Posix simply extending the list to include SIGILL and SIGSEGV
>while still allowing for other implementation-defined values?
SIGFPE, SIGILL, and SIGSEGV are the signal names defined by
POSIX.1 that correspond to computational exceptions. Elsewhere
in POSIX.1 it is stated that the implemention may generate
other, implementation-defined signals. The names of these
signals and the conditions under which they are generated
are to be documented in the POSIX conformance document.
POSIX.1 tries not to keep the implementation from providing
additional signals or errno values that give more information
to the programmer, as long as the base behavior specified
by the Standard is also supported and the appropriate
documentation is provided.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 27, Number 5
From std-unix-request@uunet.UU.NET Sat Feb 22 18:44:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA25697; Sat, 22 Feb 92 18:44:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA25754; Sat, 22 Feb 92 18:44:23 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <karish@mindcraft.com>
Subject: Re: POSIX question: dynamic linking
Message-Id: <1992Feb22.233114.16404@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Feb18.204251.3356@uunet.uu.net> <1992Feb19.202414.8126@uunet.uu.net> <1992Feb22.073646.18830@uunet.uu.net>
Date: Sat, 22 Feb 1992 17:48:10 GMT
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 article <1992Feb22.073646.18830@uunet.uu.net> cmr@cvedc.prime.com
(Chesley Reyburn) writes:
>Submitted-by: cmr@cvedc.prime.com (Chesley Reyburn)
>barmar@think.com (Barry Margolin) writes:
>>What about the kind of stuff that one needs dlopen() for, i.e. where a
>>runtime-specified module must be linked in? That's a source-level view.
The charge of the POSIX.1 committee was to codify existing
practice in the industry. I think the examples of prior art used
to represent existing practice were 4.2BSD and System 5 Release 1.
Neither of these supported dynamic linking.
>Thank you! I sent mail yesterday to Mr. Lewine stating the same
>thing and proposing something like:
>
> void *(*local_func())(char *filename, char *entryname)
>
>Where local_func() is part of POSIX. Filename is a fully qualified
>file name where the source code that describes the function may be found.
>Entryname describes the entry point in the object.
The problem, of course, is that local_func() is not part
of POSIX.1. If the POSIX.1 work were starting today,
dynamic linking would probably be a part of the committee's
work and would probably be the subject of a battle over
what model to adopt.
As Don Lewine pointed out, POSIX.1 does not contain any
concept of compiling or linking. That's handled, for now,
in an optional section of POSIX.2. The right place for
dynamic linking in the POSIX scheme would be in POSIX.1, but
it would require a change in that standard's scope as
well as consideration of the constraints this would
impose on other standards.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 27, Number 5
From std-unix-request@uunet.UU.NET Sun Feb 23 17:58:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA21356; Sun, 23 Feb 92 17:58:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA05442; Sun, 23 Feb 92 17:57:51 -0500
Newsgroups: comp.std.unix
From: Chesley Reyburn <cmr@cvedc.prime.com>
Subject: Re: POSIX question: dynamic linking
Message-Id: <1992Feb23.225202.2728@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Computervision R&D, Beaverton OR
References: <1992Feb18.204251.3356@uunet.uu.net> <1992Feb19.202414.8126@uunet.uu.net> <1992Feb22.073646.18830@uunet.uu.net> <1992Feb22.233114.16404@uunet.uu.net>
Date: Sun, 23 Feb 1992 19:57:38 GMT
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: cmr@cvedc.prime.com (Chesley Reyburn)
karish@mindcraft.com (Chuck Karish) writes:
>As Don Lewine pointed out, POSIX.1 does not contain any
>concept of compiling or linking. That's handled, for now,
>in an optional section of POSIX.2. The right place for
>dynamic linking in the POSIX scheme would be in POSIX.1, but
>it would require a change in that standard's scope as
>well as consideration of the constraints this would
>impose on other standards.
I am really confused by a scope that allows things such as
fork() and longjmp() and not dynamic linking. I actually
don't care how POSIX makes the source code specified in
local_func() available to me. It can use mutated cockroaches
instead of compilers for all I care. :-> I just want functional
access to source code specified during execution.
I realize that the books are written and the standards published.
But standards are revised from time to time. Especially if they
are used a lot. I expect POSIX to get used a LOT. What I would
like is an agreement in principle that the next time POSIX.1 gets
revisited, dynamic linking gets included.
Chesley Reyburn cmr@cvedc.prime.com
ECAE Software, Prime Computer, Inc. Phone: 503/645-2410
14952 NW Greenbrier Parkway Beaverton, OR 97006-5733, USA
Volume-Number: Volume 27, Number 6
From std-unix-request@uunet.UU.NET Mon Feb 24 18:11:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA07269; Mon, 24 Feb 92 18:11:50 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16962; Mon, 24 Feb 92 18:11:28 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <pc@hillside.co.uk>
Subject: Standards Update - Editorial
Message-Id: <1992Feb24.230506.19550@uunet.uu.net>
Reply-To: stephe@mks.com
X-Submissions: std-unix@uunet.uu.net
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:51:13 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
ENOBANDWDTH
Stephe Walli
USENIX Standards Report Editor
[ENOBANDWDTH] - No Band Width Left An asynchronous signal was caught
(such as SIGBALLOT, SIGPLSCOMMENT or SIGMORE2RD; See the description of
<signal.h> in 3.3.1) while the programmer process was busy dealing
with the last such signal. The current handler shall be interrupted
after attempting to save context, and the new handler begins to
execute. Signals shall continue to be delivered, interrupting one
another, until {_POSIX_LAST_STRAW} is reached. (See description of
Run- Time Randomly Varying Values in 2.8.4.1; Please note sysconf()
always returns either a value of one greater than the true value at
any particular time, or the return value from rand().) Once the true
value of {_POSIX_LAST_STRAW} is reached, the entire precarious stack
comes clattering down. The last interrupt handler with enough context
to still maintain some semblance of integrity returns [ENOBANDWDTH].
A programmer process may attempt to notify its parent process of the
condition in an implementation defined way, but it shall be ignored.
All joking aside, POSIX is finally beginning to strain the seams of
the working groups, along with the standards process in which it lives.
There was a time when POSIX meant a working group of around 20 people
defining a system interface for source code portability, based on the
C language interface to UNIX (356 pages). Then it started to grow.
The shell and utilities were added (~ 900 + ~ 300 pages) making
POSIX.2. Someone thought conformance testing should be done in a
standard way, and since they started suspecting POSIX was going to
grow some more, they decided to make a standard for defining test
methods (47 pages). Then there were the test methods themselves.
(Another 500 pages each for POSIX.1 and POSIX.2 so far.) Then came
real-time, to take all the real-time sorts of things that POSIX.1
couldn't settle on, along with a few things of interest only to the
real-time community. (Another ~ 400 pages, plus threads.)
You can continue in this vein for quite some time. The POSIX.20 (Ada
Bindings for POSIX.4/.4a Real-time services) project has recently
started up. This doesn't take into account the other related IEEE
Technical Committee on Operating Systems standards (P1201 GUIs, P1224
X.400, P1238 FTAM).
The working groups NOW number between 350 and 400 people, who attend
four one week long meetings a year. (As an aside, do the back of the
envelope calculation as to the amount of money that represents. Using
350, $2000/week expenses, and a loaded staff cost of another
$1500/week, I get $4,900,000/year.) The working groups generate a
considerable quantity of reading material, documenting discussions and
decisions, reviewing and co-ordinating with related efforts, proposing
alternatives, and commenting on other proposals. This all on the way
to producing the actual draft document to ballot as a standard.
An average C programmer or applications designer would likely be
interested in the base interfaces (POSIX.1), most of the real-time
services (POSIX.4), some security (POSIX.6), and possible some of the
networking (Transparent File Access - POSIX.8, and Protocol Independent
Communications - POSIX.12). And of course the shell (POSIX.2/.2a).
Whew! That's a lot of paper. POSIX Zen koan: Does a tree scream in
the wilderness every time a new project request is approved?
Before all the Ada and Fortran programmers start howling about the
``C'' programmer reference, let me explain. Until recently, the Ada or
Fortran involvement in POSIX has been two small working groups who
realised very early in the game that this standard was going to be
extremely important. They have each now produced a standard binding of
their respective languages to the C-based POSIX.1 standard.
The Ada working group is now beginning to address POSIX.4 and
POSIX.4a. The Fortran working group is beginning a Fortran 90 version
of POSIX.1 (the original POSIX.9 standard being an F77 binding.) These
groups are well placed to begin opening the way for a large segment of
the systems building community that doesn't work in C to gain access
to the benefits of a standard systems interface. They are, however,
the exceptions to date, rather than the rule.
With several vendors delivering POSIX.1 interfaces and POSIX.2 shells
on their non-UNIX derived operating systems, the growth of interest in
POSIX based open systems is only just beginning. This could bring in
a badly needed injection of new blood to the POSIX working groups. BUT
these people will not have the often needed historical context. They
will require some time in the system to come up to speed on all of its
perversities.
Let's argue that you do care about all of these related base
standards. (You should! They are being forced upon you in many
cases.) That means you should be involved enough to at least ballot.
Maybe not every section of every document, but certainly sections in
each of these drafts. You cannot standby idly trusting that a good
standard will fall out of the end of the process, and you can then use
it. If you are a member of a technical user group such as USENIX, then
the only difference between you and the people building the POSIX
standards are that they've found the financial support of their
organisations to attend the meetings. Think about it.
If you cannot attend the meetings, then you should ballot the draft
documents. (Ballot early! Ballot often!) But this then brings us back
to [ENOBANDWDTH]. The balloting schedule for 1992 (as taken from a
balloting status report of last December) looks something like the
table.
Project Ballot Date Size
_______________________________________________________________
POSIX.0 (Guide) 1st Ballot July 92 ~250 pgs
POSIX.1a (More .1) 1st Ballot Summer 92 ~100 pgs
POSIX.1/LIS 1st Ballot Spring 92 ~400 pgs
POSIX.2a (UPE) 3rd Recirc Jan 92 ~300 pgs
POSIX.3.2 (.2 Test methods) 1st Ballot Spring 92 ~500 pgs
POSIX.4 (Real-time) 3rd Recirc Spring 92 ~320 pgs
POSIX.4a (Threads) 1st Recirc Winter 92 ~200 pgs
POSIX.4b (More Real-Time) 1st Ballot Fall 92 tbd
POSIX.5 (Ada) Final Spring 92 ~300 pgs
POSIX.10 (Super. AEP) 1st Ballot July 92 ~75 pgs
POSIX.12 (Protocol Indep.) 1st Ballot Fall 92 ~400 pgs
POSIX.13 (Real-time AEP) 1st Ballot Spring 92 ~80 pgs
POSIX.15 (Batch) 1st Ballot July 92 ~175 pgs
POSIX.16 (C Binding) 1st Ballot Spring 92 ~200 pgs
POSIX.17 (Direct. Serv.) 1st Ballot Spring 92 tbd
POSIX.18 (PEP) 1st Ballot Spring 92 tbd
A few of these are a little bit specialized, such as POSIX.10
(Supercomputing Profile), POSIX.13 (Real-time Profiles), POSIX.15
(Supercomputing Batch Interfaces), and POSIX.17 (Directory Services).
Note, however that these are the smaller documents. And I haven't
mentioned the non- POSIX TCOS standards from P1201 (GUI), P1224
(X.400), and P1238 (FTAM) that are also sending drafts to ballot in
1992.
After a punishing year of balloting in 1991, the Ballotting Vice-Chair
is staging the drafts so as to not completely bury the balloting
groups in which there is often a lot of overlap. This means a working
group had better hit its target date, or it will be left stuck
circling the balloting schedule, looking for another time slot to hit.
This heavy balloting load is starting to lead to the break down of the
mock balloting process. In the ``good ol' days'' a document could be
sent to mock ballot to test the waters, before committing to the
serious work of a formal ballot. With so many documents out for
formal ballot, most mock ballots are finding themselves at the bottom
of the pile. [ENOBANDWDTH]
The heavy balloting of large documents to large balloting groups is
beginning to take its toll in other ways. The IEEE Standards Office
can no longer absorb the entire cost of copying and distribution. For
the first time in POSIX's history, the current invitation to ballot is
charging a fee per document ($25) to join the group. [ENOFINANCES]?
We've really only touched on the balloting load. If you are serious,
and you find the financing, you can look forward to spending four
weeks a year in exotic locations like Parsippany, New Jersey, at the
working group meetings. If you stick strictly to a working group or
two, you will actually be able to get out of the hotel for dinner.
(Parsippany didn't have a lot to offer here, but then we have been to
New Orleans.)
If you are interested in any of the cross group issues, such as
Language Independent Specifications, Conformance Testing, or most
important of all, the overall structure of the POSIX standards, and
the process of building it, you can look forward to six 12 to 13 hour
days (not five).
If you are a serious participant, i.e. you actually do work between
meetings, you probably spend at least another week of your time on
POSIX for every week of meeting time. Unless you are self-employed,
it is unlikely you do this in plain sight at your place of business.
It's generally frowned upon. After all, your manager already feels he's
paying for you to attend four of these ``conferences'' a year.
[ENOSUPPRT]?
It is often surprising to discover how little corporate support exists
for people in the process. There are many stories of people who cannot
find the consistent support to participate, either moral or financial,
who work for companies you would assume have an obvious stake in POSIX.
While their companies love to bask in the glow of their ``obvious
commitment to open systems'', their people are put through the wringer
trying to get the job done right. (Please see the last line of the
ENOBANDWDTH definition again.)
So the coming year will be interesting. As many of the POSIX projects
reach ballot, the number of documents circulating in ballot grows. The
relentless and blind pressure from the market place to build more
standards faster, will grow, rather than fade. The number of POSIX
projects will continue to grow, before we've even figured out how the
current ones integrate. Hark - I hear a tree screaming.
Volume-Number: Volume 27, Number 7
From std-unix-request@uunet.UU.NET Mon Feb 24 18:12:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA07271; Mon, 24 Feb 92 18:12:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16943; Mon, 24 Feb 92 18:11:23 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <pc@hillside.co.uk>
Subject: Standards Update, POSIX.4, POSIX.4a, POSIX.13, POSIX.4b Real-time Extensions
Message-Id: <1992Feb24.230603.19744@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:52:47 GMT
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: pc@hillside.co.uk (Peter Collinson)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on POSIX.4, POSIX.4a, POSIX.13, POSIX.4b Real-time Extensions
Bill O. Gallmeister <bog@lynx.com> reports on the January 13-17
meeting in Irvine, CA:
Summary
This meeting, we concentrated on the real-time profiles document
(POSIX.13), and on the new real-time interfaces (POSIX.4b). POSIX.13
was released to ballot at the end of this meeting. In addition,
technical reviewers for POSIX.4 and POSIX.4a were able to make good
progress on their respective drafts. POSIX.4 may complete balloting
in the Fall of 1992; POSIX.4a will probably take another six months
after that. Our current intention is to ballot POSIX.4b after the
October meeting. By that time, POSIX.4 itself should be through the
IEEE balloting process and into an ISO ballot, though we will probably
still be balloting POSIX.4a.
POSIX.13: Real-Time Profiles
The big news here is that POSIX.13 is now ready to ballot! After a
number of small mock ballots, the working group closed on what should
be the functionality in each of the four profiles contained in
POSIX.13. POSIX.13 is the first POSIX profile document to reach
ballot. With any luck, we will begin POSIX.13 ballot resolution at the
April, 1992 meeting.
POSIX.4b: New Real-Time Interfaces
Our goal this week was to settle on the contents of POSIX.4b and to
produce first drafts of each chapter. We came close. Some first
chapter drafts should be coming in the mailings.
POSIX.4b includes chapters for: interrupt control; timeouts on all
blocking functions; enhanced memory allocation; sporadic server
scheduling; spawn (a combined fork/exec); the ability to wait on
multiple things, also known as event flags; CPU time budgeting (the
ability to set time budgets for other processes/threads and examine
time spent by those processes/threads); and more interfaces for
driver/application communication (i.e., ioctl). Some of these
chapters actually did make it into the draft by Friday. Other
facilities were brand new, and are still being debated (CPU time
budgeting, event flags and ioctl were especially contentious). The
contents are not cast in stone, but it indicates the small groups
which the working group will form at the next meeting.
Ioctl
The standard method of driver/application communication, aside from
the obvious read/write, is ioctl. POSIX.1 elected not to standardize
ioctl, instead preferring to provide alternate standard interfaces to
control those devices, such as TTYs, for which a standard set of ioctls
existed. For devices which were not standard, POSIX.1 did not wish to
provide a standard interface for doing non- standard things.
There was some agreement with this approach in POSIX.4, but the idea
had been raised that perhaps there were a suitable set of standard
devices which might benefit from standard ioctls (SCSI devices, IEEE
488 devices, and so forth).
A small group (me) gathered up a list of standard devices for
consideration for a standardized control interface. Whether the
interface was ioctl or not is, at this point, largely immaterial.
When this list was presented, it was rather short; it turned out that
most of the impetus for ioctl is not the desire to perform standard
I/O operations (rewind a tape, eject a floppy), but rather to do non-
standard things (rotate a radar, drop some control rods, e.g.). We
decided to form a small group to further explore this issue.
Enhanced Memory Allocation
An interface by which memory can be allocated from various special
pools (NVRAM, Video Ram, for instance) is standard practice in much of
the real-time community. This is the idea behind an enhanced memory
allocation interface. It was pointed out that the mmap() facility
could be used to carve off parts of an appropriate memory area, and an
allocator could be easily constructed at application level based on
this. This was seen to be the correct way of allocating special
memory.
Asynchronous Interfaces
Some have requested that POSIX.4 provide asynchronous interfaces to
blocking services. Some objected that we have already done so;
POSIX.4a provides an asynchronous interface to any system interface by
allowing threads to be created for the purpose of using those
interfaces without suspending the original thread. For instance, an
asynchronous open routine can easily be emulated by creating a
separate thread to perform a synchronous open, then signal the
original thread and go away. Despite this, we have an agenda bullet
to explore this possibility in Dallas this April.
POSIX.4 and POSIX.4a Draft Status
POSIX.4 has completed its third round of balloting and the ballot
objections are dropping off in a gratifying fashion. The draft should
be out for its next-to-last recirculation by the April meeting. IEEE
approval is expected in the Fall of 1992. POSIX.4a is approaching its
next circulation and should be re-circulated by the Fall meeting as
well. POSIX.4a will actually be re-balloted rather than re-
circulated, because it was not able to achieve a 75% approval rate.
This means that the entire draft will be open for comment, rather than
just the parts of the draft that have changed from the previous
draft. The balloting group, however, will remain the same.
Volume-Number: Volume 27, Number 8
From std-unix-request@uunet.UU.NET Mon Feb 24 18:12:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA07273; Mon, 24 Feb 92 18:12:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16988; Mon, 24 Feb 92 18:11:32 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <pc@hillside.co.uk>
Subject: Standards Update, POSIX.5, POSIX.20: Ada Bindings
Message-Id: <1992Feb24.230726.19966@uunet.uu.net>
Reply-To: dswanson@email.sp.unisys.com
X-Submissions: std-unix@uunet.uu.net
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:54:21 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on POSIX.5, POSIX.20: Ada Bindings
Del Swanson <dswanson@email.sp.unisys.com> reports on the January
13-17 meeting in Irvine, CA:
The POSIX.5 working group is producing an Ada binding to the C-based
POSIX.1 document. The group is also involved with a new project,
POSIX.20. This will be an Ada binding to the programming language
independent specification of POSIX.4 (Real-time Extensions) and
POSIX.4a (Threads).
The meeting in Irvine was spent on the finishing touches to the
POSIX.5 document, which is finishing ballot, and getting a good start
on the new POSIX.20 work.
The group had been somewhat shocked at the overwhelming positive
response to the first recirculation of the POSIX.5 document. There was
almost 90% approval by the almost 300 balloters. This is a compliment
to the great ballot resolution job on the part of the technical
reviewers. It was a slight embarrassment, however, since there were
known errors in the draft. In fact, the draft had been sent out for
recirculation even though an error had been discovered at the last
minute. We assumed that it could be fixed in the next recirculation.
The group decided to ``do the right thing'', and make one more
recirculation with minor editorial changes and a couple of error
corrections. Draft 8 is expected to be the final recirculation. It
should have a fast turn-around, and it is expected to be approved at
the June meeting of the IEEE Standards Board.
Several new members have joined the group because of their interest in
the POSIX.20 binding of the real-time extensions. They showed
themselves to be eager participants, astute observers, and acquainted
with the issues we will be facing in this task.
The single issue that will demand our attention more than any other
during the binding deliberations is how the relationship of Ada tasks
to POSIX.4a threads will be represented in the binding. As background,
most of us are convinced that the p-threads as defined in POSIX.4a will
provide an adequate capability for Ada implementations to use for a
direct mapping of Ada tasks. Further, we believe that the services
provided in the POSIX.4 materials will be sufficient for a reasonably
straight-forward implementation of Ada tasking semantics by Ada
runtime libraries.
Nevertheless, the semantics of tasks are not identical to the
semantics of threads (for example, Ada allows no orphans). Further,
since Ada as a language introduces concurrency along with the rules of
interactions, the runtime libraries of Ada implementations like to be
able to make assumptions about the state of tasks. Disrupting this
state would likely be disastrous. For example, if an application
directly aborted a thread (which had been mapped as a task) the
runtime library could become quickly confused.
Opinions about how to deal with this situation range widely, and tend
to be held strongly. Some participants believe that services such as
pthread_create() that are available via language construct (declare a
task) should not be visible to applications by direct call to the
operating system. Others believe that every interface should be made
directly visible by way of the Ada binding. Many attempts are being
made to integrate the needs of the various factions. This issue will
arise in many ways throughout the entire POSIX.20 project.
One issue that was resolved was the basic character of the binding.
The IEEE POSIX working groups have taken the lead from ISO WG15 (ISO
POSIX) that all POSIX standards will be formulated as language
independent specifications (LIS), and this will be accompanied by a
series of thin programming language bindings. While there continues
to be scepticism evidenced by some members of the group, who doubt the
wisdom (or the possibility) of this approach, we agreed that we would
be converts to the cause.
We will produce a thin binding to the LIS versions of POSIX.4 and
POSIX.4a. We will do so enthusiastically. We will help the POSIX.4
working group in so far as we can to produce a viable LIS version.
We are fortunate that a couple of our members have received funding to
give us a head start on some labor-intensive activities. The U.S. Navy
funded a solid first draft of the test assertions for POSIX.5. The
U.S. Army funded a first draft thin Ada binding (or transliteration)
of the existing C-based POSIX.4 document.
In summary, we are expecting some significant progress at our next
meeting, now that most people are oriented to the issues. Several
people have volunteered to write position papers, and to start working
on chapters to present for consideration in April.
Your Ada Snitch.
Volume-Number: Volume 27, Number 9
From std-unix-request@uunet.UU.NET Mon Feb 24 18:12:43 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA07364; Mon, 24 Feb 92 18:12:43 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA17125; Mon, 24 Feb 92 18:11:53 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <pc@hillside.co.uk>
Subject: Standards Update, U.S. Standards Technical Advisory Groups
Message-Id: <1992Feb24.230914.20351@uunet.uu.net>
Reply-To: hill@prc.unisys.com
X-Submissions: std-unix@uunet.uu.net
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Mon, 24 Feb 1992 22:56:36 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
John Hill <hill@prc.unisys.com> reports on U.S. Standards Technical
Advisory Groups
Standards, like automobiles, come in several sizes, shapes, and colors
suitable to the use to which they will be put. With cars there are
options for just about everything; from appearance, to utility, to
emissions control. Not only that, cars are also sold with features
specifically accommodating the place in which they are to be used. If
you don't have a strong grasp of what that means then try driving your
'61 Ford Fairlane down any London street during crush hour. Your car
won't fit, it's too wide. Its outside mirrors aren't a breakaway
type, so you are dangerous to pedestrians. Not to mention that you
steer on the wrong side of the car for the side of the street on which
you are driving. In London cars have features to accommodate their
situation. Just like your '61 Fairlane fits local US requirements in
the early sixties.
What does this have to do with standards? A lot. The analogy helps
highlight some of the problems of developing worldwide standards.
Driving and cars provide interesting examples. It would be helpful if
it were simpler to drive in foreign places without being a hazard to
the local inhabitants, as well as to one's self. What's more, it
would be convenient to have the same situation, in terms of driving
conditions and cars, presented all over the world. But, in the UK
there are unique local requirements for cars, just as there are in all
other nations of the world.
Consider the situation. In countries the world over, the local people
know their driving conditions better than anyone and from them can
determine the requirements for a suitable car. After all, they face
the situation every day. But conditions differ from country to
country. This places different requirements on the cars to be
operated in each country. From a producer perspective, this results in
different product variants to accommodate each country in which the
product is used. From a world user perspective, this results in
inconvenience during use. (It does however, simplify the matter of
determining where you are. All you have to do is look at the car
you're driving.) From a general interest perspective, it is confusing
at best and baffling at its worst.
Information technology exhibits many of the same properties as cars.
In the case of telecommunications, there truly are a multitude of
factors which take on local values. One trivial example is the
assignment of characters to numbers on the telephone keypad. A
tougher problem is the variability in the quality of phone line
service across the broad spectrum of transmission rates. Please
recognize that these examples are objective, deterministic and based on
universally accepted physical laws and phenomena. Software is, well,
softer. In any event, there is great interest in having a single
worldwide standard wherever feasible.
Standards bodies
Enter IEC, CCITT and ISO. These are the organizations which develop
formal worldwide standards. Their names are actually French and won't
be cited here. It is useful to recognize that, as a general
characterization of their scopes, they handle electrotechnical (e.g.
safety, EMI), telecommunications (e.g. ISDN) and everything else (e.g.
food storage, mechanical contraceptive devices, fuels and lubricants)
respectively. Development of standards for information technology
spans the traditional boundaries of both ISO and IEC and, as such, is
managed jointly by both ISO and IEC in Joint Technical Committee 1
(JTC1).
The membership of ISO, IEC, CCITT and JTC1 is at a higher level than
organizations. CCITT is a treaty organization; the U.S. is
represented by the Department of State. ANSI represents the U.S. as
the member body in ISO, the national committee in IEC, and the
national body in JTC1. AFNOR, BSI, SIS, DIN and ON, as examples, are
the national body representatives of France, the UK, Sweden, Germany
and Austria respectively. Other standards bodies participate in a
limited manner. The most visible of these is the regional standards
developer, the European Computer Manufacturers' Association (ECMA).
If one were to examine the scope of technical activity of JTC1, the
unavoidable conclusion is that it's broad and deep. Not only does it
cover a lot of ground (media to programming languages) but also in
excruciating detail. It is unrealistic to expect that a single
organization can develop and promote a national body position in all
the JTC1 technical activities. In the U.S., the concept of Technical
Advisory Group (TAG) was put forward to handle this.
Tags
TAGs are enabled by ANSI to develop the U.S. position on a limited set
of items for specifically identified JTC1 activities. What's that
mean? Essentially, that ANSI assigns to individual standards bodies
the responsibility of handling U.S. technical interest for specific
international standards activities.
Most of the time the enabling of specific organizations to act as a
TAG for an international standards development effort is simple and
not controversial. Individual programming languages, developed in
working groups of JTC1 subcommittees, are typically simple. For
example, there is only one U.S. group developing standards for POSIX,
IEEE's P1003, and one for COBOL, X3's technical committee, X3J4. As a
result, the identification of the TAG for those working groups is
straight forward.
Sometimes the assignment of TAG responsibility is not so easy. Take
the example of JTC1's subcommittee on languages, SC22. There are
several U.S. standards development organizations which make-up the TAG
to SC22. The IEEE has POSIX and Modula-2; CODASYL has FIMS; the
Department of Defense has Ada; and X3 has a multitude of others.
Within X3, a subgroup manages the issues that overlap those TAGs or
that do not fall within the activities of any of them.
As a sidelight allow me to point out that the U.S. even needs a TAG to
JTC1 itself.
Let's regroup for a moment. There are TAGs in the U.S. for all levels
of ISO, IEC, CCITT and JTC1 in which the U.S. has an interest. Using
JTC1 as a representative example, this means there are TAGs with
responsibility for JTC1 itself, for the JTC1 subcommittees, for the
JTC1 special working groups, for the JTC1 technical subcommittees, and
for the working groups of each JTC1 technical subcommittee in which
the U.S. is interested. If there is activity anywhere within JTC1
that is of interest to the U.S., there is a TAG. Someone has to do
the work.
Work of TAGS
A logical question now is "What are these TAGs empowered to do?"
Simple question, but a complex answer. There are, however some rules
of thumb to help out.
- the more important the decision, the higher the U.S. consensus
that is required
- the more detailed and technical the subject, the higher the
weight given to the opinions of technical experts
Some examples are useful. One action JTC1 places a heavy value on is
the final approval of standards. As a result, JTC1 rules require that
a ballot be taken of its members (remember them, they're the
representative national standards organizations) for adopting a
document as a worldwide standard. Similarly, JTC1 members must vote to
approve new work items. One way to think of this is that JTC1 makes
decisions that affect the beginning (i.e. approval of new work items)
and ending (i.e. final approval) for standards. JTC1 also makes all
decisions involving the establishment and dissolution of its immediate
subgroups.
JTC1 TAG establishes the U.S. positions on matters such as new work
items and final approval of standards.
Let us examine a lower level, technical decision of JTC1. If we apply
the second rule from above, we will conclude that the decisions at
this level are delegated to the working group (of the technical
subcommittee of JTC1). One such decision is the determination of what
text should be contained in a draft standard. It doesn't get much more
detailed or technical than that. The working group determines that.
All by themselves.
There is a whole world of grey between the two examples cited above.
Typically the decisions revolve around ``recommendations to forward''
documents in various stages of completion for consideration or
approval by higher authority committees. A complete description of the
decisions and recommendations is not really appropriate for this
article. However, if you're interested allow me to point you to two
companion documents.
- the JTC1 directives (available from ANSI)
- the JTC1 TAG technical document 1 (available from CBEMA)
They are in the form of procedures but for ease of use have
comprehensive indices.
There are a few messages for you to carry away.
- TAGs are empowered by ANSI
- TAGs represent the U.S.
- there are TAGs for every worldwide standards activity that is of
interest to the U.S.
- the more important the decision, the higher the need for national
body consensus; the more technical the decision, the lower the
need for national body consensus
This has been a brief exposure of technical advisory groups in the
U.S.. As you have observed, the subject is complicated. The best way
to understand them is to join one that is in your particular area of
interest and expertise. Rather than fuss and fret about the problems
you see with them, it is recommended that you become a part of the
solution.
Volume-Number: Volume 27, Number 11
From std-unix-request@uunet.UU.NET Wed Feb 26 15:30:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16267; Wed, 26 Feb 92 15:30:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29715; Wed, 26 Feb 92 15:30:08 -0500
Newsgroups: comp.std.unix
From: proto@mitchell.hac.com
Subject: X/Open's XTI standard & OSF's TLI standard
Message-Id: <1992Feb26.202311.17679@uunet.uu.net>
Keywords: XTI, TLI, API
Reply-To: proto@mitchell.hac.com
X-Submissions: std-unix@uunet.uu.net
Organization: Hughes Aircraft Company
Date: Tue, 25 Feb 1992 18:51:06 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: proto@mitchell.hac.com
Does anyone out there have any information regarding
X/Open's XTI (X/Open Transport Interface) API standard
or OSF's TLI (Transport Layer Interface) API?
We are presently looking into incorporating one of the
above API standards into our applications, and therefore
need more information about them. I'm interested
finding out what the status of these standards is, how
to obtain a copy of the standard, and if any
implementations exist.
I'll post a summary of the volume of responses warrant it.
thanks in advance.
-----------------------------------------------------------
Scott Thomas |
Space & Communications Group | ...still searching for
Hughes Aircraft Co. | the perfect sigature...
sthomas@mitchell.eos.scg.hac.com |
Volume-Number: Volume 27, Number 14
From std-unix-request@uunet.UU.NET Wed Feb 26 15:31:13 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16301; Wed, 26 Feb 92 15:31:13 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29720; Wed, 26 Feb 92 15:30:09 -0500
Newsgroups: comp.std.unix
From: peter da silva <peter@ficc.ferranti.com>
Subject: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <1992Feb26.202224.17514@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Tue, 25 Feb 1992 21:51:30 GMT
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@ficc.ferranti.com (peter da silva)
Peter Collinson noted in the recent Standards Update that there was
opposition to a standard non-blocking system call interface, on the
grounds that the threads interface provided the same functionality.
For the case where threads are implemented in user mode, or as a side
effect of threads, it's likely that most implementations will have
some such facility anyway. Given this, I think it would be highly
desirable to spell out a standard interface, whether or not the facility
itself is mandated.
In the past I have seen two families of interfaces to this, either one
of which would be acceptable: In the first, you allocate some sort of
magic token (LUNs, Event Flags, Signal Bits, etc...) from a pool, and
pass them to the asynchronous call interface. You can later test or wait
on these tokens to see if an event has occurred. The other interface is
for the async call to return a token which you can use later, similar to
the way UNIX file handles work.
Personally, I prefer the latter interface. It's similar to the existing
UNIX open/read/write setup, and the tokens could even be file descriptors
in some implementations.
Volume-Number: Volume 27, Number 13
From std-unix-request@uunet.UU.NET Wed Feb 26 15:31:14 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16304; Wed, 26 Feb 92 15:31:14 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29774; Wed, 26 Feb 92 15:30:19 -0500
Newsgroups: comp.std.unix
From: "Mike Wulkan" <WULKAN@torolab6.vnet.ibm.com>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb26.202432.17940@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
References: <1992Feb22.232957.16129@uunet.uu.net>,
Date: Wed, 26 Feb 1992 13:08:42 GMT
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@TOROLAB6.VNET.IBM.COM ("Mike Wulkan")
In article <1992Feb22.232957.16129@uunet.uu.net>,
karish@mindcraft.com (Chuck Karish) writes:
>SIGFPE, SIGILL, and SIGSEGV are the signal names defined by
>POSIX.1 that correspond to computational exceptions. Elsewhere
>in POSIX.1 it is stated that the implementation may generate
>other, implementation-defined signals. The names of these
>signals and the conditions under which they are generated
>are to be documented in the POSIX conformance document.
>
>POSIX.1 tries not to keep the implementation from providing
>additional signals or errno values that give more information
>to the programmer, as long as the base behavior specified
>by the Standard is also supported and the appropriate
>documentation is provided.
I had no question regarding additional implementation defined signals.
My question was whether an implementation could choose to designate one
of the other Posix defined signals as "computational" with regards to
the undefined behaviour when returning from a handler? I think the
answer is no.
On a similar note, there seems to be a contradiction in the
section describing SIG_IGN which reads:
"Delivery of the signal shall have no effect on the process.
The behavior of a process is undefined after it ignores a SIGFPE,
SIGILL, or SIGSEGV signal ..."
Why would the behavior of a process be UNDEFINED if the signal has NO
EFFECT on the process? Obviously the signal has an effect! Why not
simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
is done for SIGKILL and SIGSTOP? At the very least it would seem that
the section would be more accurately worded:
The behavior of the process is undefined after a SIGFPE, SIGILL, or
SIGSEGV signal is delivered, otherwise delivery of the signal shall
have no effect on the process.
Mike Wulkan
Volume-Number: Volume 27, Number 15
From std-unix-request@uunet.UU.NET Wed Feb 26 15:39:48 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17304; Wed, 26 Feb 92 15:39:48 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA02493; Wed, 26 Feb 92 15:39:46 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb26.202135.17342@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <1992Feb22.073722.18969@uunet.uu.net>
Date: Mon, 24 Feb 1992 22:49:35 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1992Feb22.073722.18969@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM (Mike Wulkan) writes:
>Is the intent of Posix to "limit" the scope of "other
>implementation-defined value" to exactly SIGFPE, SIGILL and SIGSEGV?
>Or is Posix simply extending the list to include SIGILL and SIGSEGV
>while still allowing for other implementation-defined values?
The latter.
Volume-Number: Volume 27, Number 12
From std-unix-request@uunet.UU.NET Wed Feb 26 18:03:11 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00795; Wed, 26 Feb 92 18:03:11 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15192; Wed, 26 Feb 92 18:03:07 -0500
Newsgroups: comp.std.unix
From: Michael I Bushnell <mib@geech.gnu.ai.mit.edu>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb26.225705.1510@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Free Software Foundation, Cambridge, MA
References: <1992Feb22.232957.16129@uunet.uu.net>, <1992Feb26.202432.17940@uunet.uu.net>
Date: Wed, 26 Feb 1992 22:02:49 GMT
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: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan") writes:
On a similar note, there seems to be a contradiction in the
section describing SIG_IGN which reads:
"Delivery of the signal shall have no effect on the process.
The behavior of a process is undefined after it ignores a SIGFPE,
SIGILL, or SIGSEGV signal ..."
Why would the behavior of a process be UNDEFINED if the signal has NO
EFFECT on the process? Obviously the signal has an effect! Why not
simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
is done for SIGKILL and SIGSTOP? At the very least it would seem that
the section would be more accurately worded:
The behavior of the process is undefined after a SIGFPE, SIGILL, or
SIGSEGV signal is delivered, otherwise delivery of the signal shall
have no effect on the process.
It isn't the signal that has the effect. It's that the machine will
do something odd. For example, on a Vax, an illegal memory reference
is a fault. If the generated signal is ignored, the result is an
infinite loop. It is useful for the OS to specify this. On the other
hand, it is also useful for Posix to leave it undefined, because
different hardware and different OS's recover from such things
differently.
If you just do `kill -ILL 387', and process 387 has set the handler
for SIGILL to SIG_IGN, truly nothing should happen. I believe Posix
should specify this, but I don't believe it does.
The confusion here is between the hardward (implementation-defined)
event causing the signal and the signal itself.
Your suggested fix is not adequate, however. People should be able to
catch illegal references in programs, and then be able to exit nicely.
Your "fix" precludes doing so portably.
-mib
--
Michael Innis Bushnell | This is a virulent meme. Whether or not you place
Email: mib@gnu.ai.mit.edu | this into your signature file is irrelevant. You
Phone: (617) 625-4518 | have already participated in its further trans-
| mission, and will doubtless continue to do so.
Volume-Number: Volume 27, Number 17
From std-unix-request@uunet.UU.NET Wed Feb 26 18:03:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00812; Wed, 26 Feb 92 18:03:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15417; Wed, 26 Feb 92 18:03:46 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <henry@zoo.toronto.edu>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <1992Feb26.225630.1375@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: U of Toronto Zoology
References: <1992Feb26.202224.17514@uunet.uu.net>
Date: Wed, 26 Feb 1992 22:14:20 GMT
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 <1992Feb26.202224.17514@uunet.uu.net> peter@ficc.ferranti.com (peter da silva) writes:
>...opposition to a standard non-blocking system call interface, on the
>grounds that the threads interface provided the same functionality.
>
>For the case where threads are implemented in user mode, or as a side
>effect of threads, it's likely that most implementations will have
>some such facility anyway. Given this, I think it would be highly
>desirable to spell out a standard interface, whether or not the facility
>itself is mandated.
Except that somebody, like the clots at NIST, will then demand that
everyone implement it. This is properly a detail of the *implementation*
of threads, and should be left to the implementors.
The point is, the user gets access to the functionality by using threads.
There is no gain to him in having another interface documented, especially
if it is one that might or might not be present, and especially if -- as
with non-blocking syscalls -- it leads to messier and buggier code
than the interface that is already provided. (Every non-blocking-calls
program I've ever seen has had a threads program inside, screaming to
get out.)
--
The X Window system is not layered, and | Henry Spencer @ U of Toronto Zoology
it was not designed. -Shane P. McCarron | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 27, Number 16
From std-unix-request@uunet.UU.NET Fri Feb 28 19:11:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05204; Fri, 28 Feb 92 19:11:47 -0500
Received: from kithrup.COM (via [140.174.1.40]) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22749; Thu, 27 Feb 92 21:06:56 -0500
Newsgroups: comp.std.unix
From: "Mike Wulkan" <WULKAN@torolab6.vnet.ibm.com>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb28.005415.22973@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
References: <1992Feb26.225705.1510@uunet.uu.net>,
Date: Thu, 27 Feb 1992 13:28:45 GMT
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@TOROLAB6.VNET.IBM.COM ("Mike Wulkan")
In article <1992Feb26.225705.1510@uunet.uu.net>,
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>If you just do `kill -ILL 387', and process 387 has set the handler
>for SIGILL to SIG_IGN, truly nothing should happen. I believe Posix
>should specify this, but I don't believe it does.
>
>The confusion here is between the hardware (implementation-defined)
>event causing the signal and the signal itself.
>
>Your suggested fix is not adequate, however. People should be able to
>catch illegal references in programs, and then be able to exit nicely.
>Your "fix" precludes doing so portably.
No, my "fix" was only in reference to SIG_IGN. You can still specify
a signal catching function and then longjmp, exit or abort "nicely".
There is nothing portable about the current Posix definition of
ignoring (via SIG_IGN) a SIGSEGV, SIGILL or SIGFPE signal since it
specifically says that the behavior of the process after the signal
is delivered is undefined.
Mike Wulkan
Volume-Number: Volume 27, Number 19
From std-unix-request@uunet.UU.NET Fri Feb 28 19:12:14 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05233; Fri, 28 Feb 92 19:12:14 -0500
Received: from kithrup.COM (via [140.174.1.40]) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22838; Thu, 27 Feb 92 21:07:26 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <karish@mindcraft.com>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb28.005506.23144@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Feb22.232957.16129@uunet.uu.net> <1992Feb26.202432.17940@uunet.uu.net>
Date: Thu, 27 Feb 1992 15:12:31 GMT
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 article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM
("Mike Wulkan") writes:
>I had no question regarding additional implementation defined signals.
>My question was whether an implementation could choose to designate one
>of the other Posix defined signals as "computational" with regards to
>the undefined behaviour when returning from a handler? I think the
>answer is no.
I agree.
>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process?
Because the event that caused the signal to be generated
has already corrupted the process's execution environment.
>Obviously the signal has an effect!
When it's ignored?
>Why not
>simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
>is done for SIGKILL and SIGSTOP?
Because the process can sometimes exit gracefully. No
guarantee, though.
>At the very least it would seem that
>the section would be more accurately worded:
>
> The behavior of the process is undefined after a SIGFPE, SIGILL, or
> SIGSEGV signal is delivered, otherwise delivery of the signal shall
> have no effect on the process.
The behavior of the process is defined after one of these
signals is delivered: abnormal termination. The second
sentence is unnecessary, because the process of catching a
signal is already well defined. By re-writing this, you've
removed the warning that the signals in question indicate
that the process is in trouble from which the operating
system can not rescue it.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 27, Number 20
From std-unix-request@uunet.UU.NET Fri Feb 28 19:12:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05264; Fri, 28 Feb 92 19:12:47 -0500
Received: from kithrup.COM (via [140.174.1.40]) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22693; Thu, 27 Feb 92 21:06:40 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: return from a signal-catching function
Message-Id: <1992Feb28.005311.22787@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <1992Feb22.232957.16129@uunet.uu.net> <1992Feb26.202432.17940@uunet.uu.net>
Date: Thu, 27 Feb 1992 10:16:13 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan") writes:
>On a similar note, there seems to be a contradiction in the
>section describing SIG_IGN which reads:
> "Delivery of the signal shall have no effect on the process.
> The behavior of a process is undefined after it ignores a SIGFPE,
> SIGILL, or SIGSEGV signal ..."
>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process? Obviously the signal has an effect!
The first sentence states the general rule; the second then modifies it
with particular exceptions. That in fact reflects the way the signal
mechanism evolved and the way that we think about it.
>Why not simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and
>SIGSEGV as is done for SIGKILL and SIGSTOP?
The effect as worded is to render such programs not maximally portable
anyway. (In Standard C parlance they would be "not strictly conforming".)
In the course of preparing such standards, often there was political
pressure to "not disallow" certain examples of existing programming
practice. Whenever the standard really could not promise semantics
for such constructs, there was the choice of forbidding them (and in
the case of the C language standard, requiring a diagnostic) or
allowing them with caveats about their non-portability. Often the
latter was more acceptable to the standards group than the former.
I no longer recall why our signals working subgroup ended up with the
exact wording you cited, but my guess is it was partly practical
politics aimed at arriving at a consensus.
>At the very least it would seem that
>the section would be more accurately worded:
> The behavior of the process is undefined after a SIGFPE, SIGILL, or
> SIGSEGV signal is delivered, otherwise delivery of the signal shall
> have no effect on the process.
The time to make such comments is during the public review of the
proposed standard. You missed that by several years.
Volume-Number: Volume 27, Number 18
From std-unix-request@uunet.UU.NET Mon Mar 2 04:15:51 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03518; Mon, 2 Mar 92 04:15:51 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18165; Mon, 2 Mar 92 04:15:49 -0500
Newsgroups: comp.std.unix
From: peter da silva <peter@ferranti.com>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <1992Mar2.090937.20980@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Xenix Support, FICC
References: <1992Feb26.202224.17514@uunet.uu.net> <1992Feb26.225630.1375@uunet.uu.net>
Date: Fri, 28 Feb 1992 00:01:43 GMT
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 <1992Feb26.225630.1375@uunet.uu.net> henry@zoo.toronto.edu (Henry Spencer) writes:
> The point is, the user gets access to the functionality by using threads.
Well, ignoring quality of implementation issues... yes.
> There is no gain to him in having another interface documented, especially
> if it is one that might or might not be present, and especially if -- as
> with non-blocking syscalls -- it leads to messier and buggier code
> than the interface that is already provided.
Well, actually, there is... if he's working in an environment that does not
readily lead itself to coding his program in terms of threads. For example,
if he's using an X toolkit or other non-reentrant library. In this case your
threads program is going to have to end up having one master thread that does
all the I/O, and a bunch of little threads running around it that emulate a
non-blocking syscall interface.
I understand your opinion of X, and I agree with it, but unfortunately it's
a reality, and its requirement that user application programs provide
reasonably good realtime response makes it a likely place to be doing
this sort of thing.
Also, a properly designed threads interface (I don't know if the 1003.4 one
is in a "properly designed" state or not this week) doesn't expose details
like whether the threads are managed in user mode or at the kernel level.
> (Every non-blocking-calls
> program I've ever seen has had a threads program inside, screaming to
> get out.)
How many have you seen? I've seen a lot, and some are simply written under
constraints that make threads unattractive in the extreme.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
Volume-Number: Volume 27, Number 21
From std-unix-request@uunet.UU.NET Mon Mar 2 04:15:58 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03551; Mon, 2 Mar 92 04:15:58 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18180; Mon, 2 Mar 92 04:15:53 -0500
Newsgroups: comp.std.unix
From: Fred Zlotnick <fred@mindcraft.com>
Subject: Re: return from a signal-catching function
Message-Id: <1992Mar2.091024.21139@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Feb22.232957.16129@uunet.uu.net> <1992Feb26.202432.17940@uunet.uu.net>
Date: Thu, 27 Feb 1992 19:21:16 GMT
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: fred@mindcraft.com (Fred Zlotnick)
In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan") writes:
> [ ... ]
>On a similar note, there seems to be a contradiction in the
>section describing SIG_IGN which reads:
>
> "Delivery of the signal shall have no effect on the process.
> The behavior of a process is undefined after it ignores a SIGFPE,
> SIGILL, or SIGSEGV signal ..."
>
>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process? Obviously the signal has an effect! Why not
>simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
>is done for SIGKILL and SIGSTOP? At the very least it would seem that
>the section would be more accurately worded:
>
The signal has no effect. The reason the behavior is undefined is that
the process has gotten an arithmetic point exception (SIGFPE) or
has executed an illegal instruction (SIGILL) or has referenced an
address outside its address space (SIGSEGV). After any of these
exceptions, the behavior of the process is undefined.
Of course these signals can be generated by other means, for example
through kill() or raise(). These are specifically excluded by the
standard: The sentence quoted above ends
...or SIGSEGV signal that was not generated by the kill()
function or the raise() function defined by the C Standard.
Any other event that generates one of these signals is presumably
(i.e., in a reasonable implementation) another type of exception.
----
Fred Zlotnick | "A standard is a treaty between the
fred@mindcraft.com | customer and the implementor."
...!{uupsi,ames}!mindcrf!fred | Henry Spencer
#include <std/disclaimer> |
Volume-Number: Volume 27, Number 22
From std-unix-request@uunet.UU.NET Mon Mar 2 04:16:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03557; Mon, 2 Mar 92 04:16:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18190; Mon, 2 Mar 92 04:15:59 -0500
Newsgroups: comp.std.unix
From: "David J. Fiander" <davidf@mks.com>
Subject: Weirdnix .2?
Message-Id: <1992Mar2.091241.21465@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Fri, 28 Feb 1992 16:32:27 GMT
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: davidf@mks.com ("David J. Fiander")
So is there such a beast? If there is, then I have the first
entry.
According to .2D11, 'cp -R' does not have to process
subdirectories below the top level directory. For example,
given the following structure,
srcdir destdir
\
subdir
\
file
a conforming cp is perfectly capable of generating the result
srcdir destdir
\ \
subdir srcdir
\
file
when given the command line "cp -R srcdir destdir", without
generating any diagnostics.
Support: POSIX.2D11 lines 3557-3564. In particular, lines
3563-4 state "It is unspecified if cp shall attempt to copy
files in the file hierarchy rooted in source_file."
[ As far as I know, there is no Son of Weirdnix. I like the
idea, however: it's been too long since we've had such a
contest, even though the C people have one once a year 8).
Is anybody willing to volunteer prizes? -- mod ]
Volume-Number: Volume 27, Number 23
From std-unix-request@uunet.UU.NET Mon Mar 2 04:16:07 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03582; Mon, 2 Mar 92 04:16:07 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB18216; Mon, 2 Mar 92 04:16:04 -0500
Newsgroups: comp.std.unix
From: Bob Lenk <rml@hpfcdc.fc.hp.com>
Subject: Re: return from a signal-catching function
Message-Id: <1992Mar2.091331.21681@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
References: <1992Feb26.202432.17940@uunet.uu.net>
Date: Fri, 28 Feb 1992 01:48:43 GMT
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: rml@hpfcdc.fc.hp.com (Bob Lenk)
In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan") writes:
> On a similar note, there seems to be a contradiction in the
> section describing SIG_IGN which reads:
>
> "Delivery of the signal shall have no effect on the process.
> The behavior of a process is undefined after it ignores a SIGFPE,
> SIGILL, or SIGSEGV signal ..."
>
> Why would the behavior of a process be UNDEFINED if the signal has NO
> EFFECT on the process? Obviously the signal has an effect!
The exception that caused the signal has an effect on the process. The
signal that it causes has no effect (because it is being ignored). The
behavior of the process is then undefined by the standard because it
is whatever results from the exception.
> Why not
> simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
> is done for SIGKILL and SIGSTOP?
Because that was/is not existing practice. On some specific
implementation the results of ignoring some exception may be predictable
and even useful (eg. simply continuing to execute the instruction that
follows an attempted division by zero). There is no reason for the
standard to dictate that a non-portable application not be able to
take advantage of this.
Bob Lenk
rml@fc.hp.com
{uunet,hplabs}!fc.hp.com!rml
Volume-Number: Volume 27, Number 24
From std-unix-request@uunet.UU.NET Mon Mar 2 04:16:13 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03610; Mon, 2 Mar 92 04:16:13 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18230; Mon, 2 Mar 92 04:16:10 -0500
Newsgroups: comp.std.unix
From: Jan-Mark <jms@cs.vu.nl>
Subject: Need help with utime().
Message-Id: <1992Mar2.091505.21915@uunet.uu.net>
Keywords: utime
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Mon, 2 Mar 1992 08:33:44 GMT
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: jms@cs.vu.nl (Jan-Mark)
I have the POSIX manual 1003.1-1988 and on page 104 it states
the ``errno'' settings for a failed ``utime()'' call.
:
:
[EACCES] Search permission is denied by a component of the path
prefix; or the times argument is NULL and the effective
user ID of the process does not match the owner of the
file and write access is denied.
:
:
[EPERM] The times argument is not NULL and the calling process's
effective user ID has write access to the file but does
not match the owner of the file and the calling process
does not have the appropriate privileges.
:
:
So if user1 (!= root) does a ``utime()'' call on user2's file
four things can happen (*):
| user1 has | user1 has no
| write permission | write permission
----------------+------------------+-------------------
NULL argument | OK | EACCES
----------------+------------------+-------------------
utimbuf arg. | EPERM | <undef.>
Where <undef.> means I don't know what it should be.
Is there a way of reading the 1003.1 that will give me the
proper value? Is there a post 1988 update that does so?
If you know, please let me know!
Thanks Jan-Mark.
(*) Assuming the file is not on a read-only file system, or
on a non searchable directory etc.
Volume-Number: Volume 27, Number 25
From std-unix-request@uunet.UU.NET Mon Mar 2 04:23:22 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05441; Mon, 2 Mar 92 04:23:22 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18894; Mon, 2 Mar 92 04:23:19 -0500
Newsgroups: comp.std.unix
From: Robert Virding <rv@erix.ericsson.se>
Subject: Inconsistencies in matching betweens AWKs.
Message-Id: <1992Mar2.091734.22269@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Fri, 28 Feb 1992 16:44:21 GMT
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: rv@erix.ericsson.se (Robert Virding)
I have been implementing a set of string functions for a language
which we have developed at our lab. (Erlang, it's a real-time
concurrent high-level language for building large robust systems) As I
had need of some regular expression matching I decided to take the REs
and basic functions (match, sub, gsub and split) as defined in "The
AWK Programming Language" by Aho, Kernighan and Weinberger.
All went well until I started looking at how "awk" handles newlines
embedded in strings wrt beginning/end of string expressions. I
discovered that all the "awk"s we had acted differently. I have tried:
awk - the old "standard" one
nawk - a "new" one available on SUN (?), compatible with book
gawk - GNU awk
mawk - recently available from comp.sources.reviewed
Both gawk and mawk follow the book and conform to POSIX 1003.2 (draft
11) standard.
I enclose some small test files which show how inconsistent the
systems really are (or seem to be). Even when there were no newlines
in the string results were inconsistent. What does the standard say?
Any help would truly be appreciated.
Robert Virding @ Ellemtel Utvecklings AB, Stockholm
EMAIL: rv@erix.ericsson.se
P.S. If there is any interest I will summarise the results.
TESTS AND RESULTS
=================
Test 1
------
A simple test which all "awk"s could do. I must admit I can't really
understand what gawk and mawk are doing. Nawk is closer to what I
think would happen. But why isn't the 'f' removed in the 2nd case?
BEGIN {
s1 = "foobarbaz"
n = split(s1, a1, "^.")
print "n = " n
for (i = 1; i <= n; i++)
print ":" a1[i] ":"
s2 = "foo\nbar\nbaz"
n = split(s2, a2, "^.")
print "n = " n
for (i = 1; i <= n; i++)
print ":" a2[i] ":"
exit
}
awk nawk gawk mawk
n = 1 n = 2 n = 9 n = 10
:foobarbaz: :: :: ::
n = 3 :oobarbaz: :: ::
:foo: n = 1 :: ::
:bar: :foo :: ::
:baz: bar :: ::
baz: :: ::
:: ::
:: ::
:: ::
n = 9 ::
:: n = 12
:: ::
:: ::
: ::
: ::
:: ::
:: ::
: ::
: ::
:: ::
:: ::
::
::
Test 2
------
This test was impossible for awk (no gsub function). I will also admit
that nawk here seemd to do something which I feel is more reasonable.
BEGIN {
s1 = "foobarbaz"
gsub("^.", "X&Y", s1)
print ":" s1 ":"
s2 = "foo\nbar\nbaz"
gsub("^.", "X&Y", s2)
print ":" s2 ":"
exit
}
nawk gawk mawk
:XfYoobarbaz: :XfYXoYXoYXbYXaYXrYXbYXaYXzY: :XfYXoYXoYXbYXaYXrYXbYXaYXzY:
:XfYoo :XfYXoYXoY :XfYXoYXoYX
bar XbYXaYXrY YXbYXaYXrYX
baz: XbYXaYXzY: YXbYXaYXzY:
Test 3
------
This test was impossible for awk (no match function). Mawk here seemed the
best to me. Where nawk got its RLENGTH values from I can't understand.
BEGIN {
s1 = "foo"
match(s1, /foo$/)
print RSTART, RLENGTH
print ":" substr(s1, RSTART, RLENGTH) ":"
s2 = "foo\n\n"
match(s2, /foo..$/)
print RSTART, RLENGTH
print ":" substr(s2, RSTART, RLENGTH) ":"
exit
}
nawk gawk mawk
1 4 1 3 1 3
:foo: :foo: :foo:
1 6 0 -1 1 5
:foo :: :foo
: :
The very end
Volume-Number: Volume 27, Number 26
From std-unix-request@uunet.UU.NET Tue Mar 3 08:15:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17780; Tue, 3 Mar 92 08:15:47 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12839; Tue, 3 Mar 92 08:15:45 -0500
Newsgroups: comp.std.unix
From: Jack Jansen <Jack.Jansen@cwi.nl>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <1992Mar3.130705.13944@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
References: <1992Feb26.202224.17514@uunet.uu.net>
Date: Mon, 2 Mar 1992 15:45:10 GMT
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: Jack.Jansen@cwi.nl (Jack Jansen)
peter@ficc.ferranti.com (peter da silva) writes:
>Peter Collinson noted in the recent Standards Update that there was
>opposition to a standard non-blocking system call interface, on the
>grounds that the threads interface provided the same functionality.
>For the case where threads are implemented in user mode, or as a side
>effect of threads, it's likely that most implementations will have
>some such facility anyway. Given this, I think it would be highly
>desirable to spell out a standard interface, whether or not the facility
>itself is mandated.
Hmm, I don't think that this is a good idea. If Posix takes the
easy-way-out of sanctioning multiple solutions to the same problem
just a few times more the whole thing will become worthless. I know,
profiles are the magic word (and a good thing, in some cases) but if
you provide more than one way to do almost everything Posix will
become as useless a label as "user friendly".
--
--
Jack Jansen | In Holland things are serious, but never hopeless.
Jack.Jansen@cwi.nl | In Ireland things are hopeless, but never serious.
uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl
Volume-Number: Volume 27, Number 27
From std-unix-request@uunet.UU.NET Tue Mar 3 08:15:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17787; Tue, 3 Mar 92 08:15:50 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12850; Tue, 3 Mar 92 08:15:49 -0500
Newsgroups: comp.std.unix
From: Donn Terry <donn@hpfcrn.fc.hp.com>
Subject: Re: POSIX question: dynamic linking
Message-Id: <1992Mar3.130903.14236@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
References: <1992Feb22.233114.16404@uunet.uu.net>
Date: Mon, 2 Mar 1992 15:53:11 GMT
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: donn@hpfcrn.fc.hp.com (Donn Terry)
My opinion (which is mine, but as chair I do have a little influence :-) )
is that dynamic linking could be within scope of POSIX.1. (It might
take a PAR change, but I would personally read the current PAR to allow
it if it came from "outside" POSIX.1 originally.)
However, frequent readers of this group will be quite aware of the frequency
of flames about "invention" being done by standards bodies. Dynamic
linking definitely falls into that category.
Of course we also get flamed for not "inventing" things. Such is life.
In any case, dynamic linking is probably a useful area to start work on
development of several models so it can be determined what works well and
what doesn't. (Again, remember the flames we get for inventing something
without trying it, and many of them have much more obvious solutions than
dynamic linking.)
If someone were to come forward with a proposal that had a pretty high
level of consensus, and which was feasable to implement on a broad
range of machines, specifically including those with non-traditional
architectures (i.e. not like VAXes)), then I'm sure POSIX.1 would
consider it, and determine if consensus on doing it can be reached amongst
the participants.
However, if YOU want dynamic linking (or anything else), it's YOUR job to
make it happen. The meetings are open (but not free, unhappily...
Sugar Daddies may apply at any time.)
Donn Terry
Chair 1003.1
(Speaking only for myself.)
Volume-Number: Volume 27, Number 28
From std-unix-request@uunet.UU.NET Tue Mar 3 08:15:57 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17796; Tue, 3 Mar 92 08:15:57 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12864; Tue, 3 Mar 92 08:15:54 -0500
Newsgroups: comp.std.unix
From: Bradley Wong <bwong@beach.csulb.edu>
Subject: List of POSIX-compatible OS's?
Message-Id: <1992Mar3.130930.14342@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: TRW SEDD
Date: Mon, 2 Mar 1992 19:13:56 GMT
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: bwong@beach.csulb.edu (Bradley Wong)
Is there a fairly efficient (i.e., existing list or ??) way to
find out what vendor OS offerings are POSIX-compliant
or have announced the intention of becoming POSIX-compliant
RSN (Real Soon Now)?
Thanks,
Marc Ries
ries@micky.sedd.trw.com
Volume-Number: Volume 27, Number 29
From std-unix-request@uunet.UU.NET Tue Mar 3 08:16:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17803; Tue, 3 Mar 92 08:16:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12876; Tue, 3 Mar 92 08:15:58 -0500
Newsgroups: comp.std.unix
From: Peter Collinson <pc@hillside.co.uk>
Subject: POSIX MEETING in EUROPE - OCTOBER
Message-Id: <1992Mar3.131000.14441@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Usenix Association, Standards Liaison
Date: Tue, 3 Mar 1992 00:31:27 GMT
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: pc@hillside.co.uk (Peter Collinson)
MEETING ANNOUNCEMENT
IEEE TECHNICAL COMMITTEE ON OPERATING SYSTEMS (TCOS)
P1003 POSIX
OCTOBER 19-23, 1992
UTRECHT
The IEEE P1003 (POSIX) meeting scheduled for October 19-23, 1992 will be
held at Utrecht in the Netherlands. A major goal of this meeting is to
enable participation in the POSIX standards development process by
interested parties in Europe who may be unable to attend the meetings in
the US. This preliminary announcement is being made now in order to
allow sufficient time for advance planning by those wishing to attend.
Specific details regarding meeting registration and schedules for
individual working groups will be made available in the future.
----------------------------------------
Posted by Peter Collinson, in my guise as Usenix standards liaison. Please
don't ask me for any more specific details. I will, however, post
some contact information nearer the time.
Volume-Number: Volume 27, Number 30
From std-unix-request@uunet.UU.NET Tue Mar 3 16:13:56 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13362; Tue, 3 Mar 92 16:13:56 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23007; Tue, 3 Mar 92 16:13:50 -0500
Newsgroups: comp.std.unix
From: Bob Bagwill <bagwill@swe.ncsl.nist.gov>
Subject: Re: List of POSIX-compatible OS's?
Message-Id: <1992Mar3.210739.1433@uunet.uu.net>
Summary: posix list
Keywords: posix
X-Submissions: std-unix@uunet.uu.net
Organization: Computer Systems Lab
References: <1992Mar3.130930.14342@uunet.uu.net>
Date: Tue, 3 Mar 1992 14:57:04 GMT
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: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
In article <1992Mar3.130930.14342@uunet.uu.net> bwong@beach.csulb.edu (Bradley Wong) writes:
>Is there a fairly efficient (i.e., existing list or ??) way to
>find out what vendor OS offerings are POSIX-compliant
>or have announced the intention of becoming POSIX-compliant
>RSN (Real Soon Now)?
To get the register of the POSIX implementations which have been tested
by an accredited POSIX testing lab by email, and whose test results
have been validated by NIST, do the following (using /usr/ucb/mail as
an example):
mail posix@nist.gov
Subject: anything
path yourname@yournode
send register
end
.
To get the testing policy, add "send policy"; to get the testing
requirements, add "send requirements".
Everyone and their clone have announced POSIX-compliancy RSN. BFD.
--
Bob Bagwill NIST/Computer Systems Lab/Software Engineering Group
Volume-Number: Volume 27, Number 31
From std-unix-request@uunet.UU.NET Fri Mar 6 00:33:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA08638; Fri, 6 Mar 92 00:33:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA25162; Fri, 6 Mar 92 00:33:05 -0500
Newsgroups: comp.std.unix
From: peter da silva <peter@ferranti.com>
Subject: Re: Standards Update: POSIX.4[a] Asynchronous I/O vs. Threads.
Message-Id: <1992Mar6.052707.11315@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Xenix Support, FICC
References: <1992Feb26.202224.17514@uunet.uu.net> <1992Mar3.130705.13944@uunet.uu.net>
Date: Wed, 4 Mar 1992 18:23:13 GMT
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 <1992Mar3.130705.13944@uunet.uu.net> Jack.Jansen@cwi.nl (Jack Jansen) writes:
> Hmm, I don't think that this is a good idea. If Posix takes the
> easy-way-out of sanctioning multiple solutions to the same problem
I don't think this is the easy way out, nor that it's a solution to
the same problem.
The easy way out is to specify threads and let everyone continue to use
a bunch of inconsistent interfaces for a common capability if they can't
use threads for some reason (like, they have to support dusty-deck
runtimes like every X toolkit in existence).
The hard way is to define a consistent interface that can be provided
on a variety of systems, and while you're about it clean out some
of the cack in existing implementations (select/poll/O_NDELAY/...).
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
Volume-Number: Volume 27, Number 32
From std-unix-request@uunet.UU.NET Tue Mar 10 17:07:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04058; Tue, 10 Mar 92 17:07:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18881; Tue, 10 Mar 92 17:06:58 -0500
Newsgroups: comp.std.unix
From: "David J. Fiander" <davidf@mks.com>
Subject: sed's r and w commands
Message-Id: <1992Mar10.220045.7862@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Tue, 10 Mar 1992 13:44:07 GMT
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: davidf@mks.com ("David J. Fiander")
According to D11.2,
The r and w commands take an optional rfile (or wfile)
parameter...
(ll 11338-9). But nowhere does the standard describe the
behaviour of these commands when the "optional" parameter is
omitted. In fact, the descriptions of the commands seem to
indicate that the parameter is _not_ optional, since it is not
surrounded by square brackets.
- David
Volume-Number: Volume 27, Number 32
From std-unix-request@uunet.UU.NET Tue Mar 10 17:07:04 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04076; Tue, 10 Mar 92 17:07:04 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18901; Tue, 10 Mar 92 17:07:01 -0500
Newsgroups: comp.std.unix
From: "David J. Fiander" <davidf@mks.com>
Subject: More sed problems
Message-Id: <1992Mar10.220201.8171@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Tue, 10 Mar 1992 15:40:27 GMT
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: davidf@mks.com ("David J. Fiander")
According to the rationale, "The requirements for acceptance of
<blank>s and <space>s in command lines has been made more
explicit..."
Does that mean that I should only strip blanks preceeding
addresses and between addresses and commands? If so, does that
mean that
$a\
boo!
will append ' boo!' to the end of the file, even though this
goes against historical practice?
It is obvious that
$a\
\ boo!
will still behave the same way, since the description of _text_
works out, but nothing has been said about leading spaces in
_text_ lines.
--
David J. Fiander |EXAMPLES: 'sed 10q file' -- Print the first 10
<davidf@mks.com> |lines of a file. Some systems call this
Mortice Kern Systems Inc. |function _head_.
Waterloo, Ontario, Canada | - tail(1) man page from Research UNIX
Volume-Number: Volume 27, Number 33
From std-unix-request@uunet.UU.NET Tue Mar 10 17:07:09 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04099; Tue, 10 Mar 92 17:07:09 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18927; Tue, 10 Mar 92 17:07:06 -0500
Newsgroups: comp.std.unix
From: J Lee Jaap <jaapjl@tab00.larc.nasa.gov>
Subject: Re: List of POSIX-compatible OS's?
Message-Id: <1992Mar10.220607.8828@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: AS&M Inc
References: <1992Mar3.130930.14342@uunet.uu.net> <1992Mar3.210739.1433@uunet.uu.net>
Date: Tue, 10 Mar 1992 20:56:40 GMT
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: jaapjl@tab00.larc.nasa.gov (J Lee Jaap)
In article <1992Mar3.210739.1433@uunet.uu.net> bagwill@swe.ncsl.nist.gov (Bob Bagwill) writes:
>To get the testing policy, add "send policy"; to get the testing
>requirements, add "send requirements".
-------> ^^^^^^^^^^^^
That should be "send required".
--
J Lee Jaap <jaapjl@tab00.larc.nasa.gov> {+1 804/864, or FTS 928}-2148
employed by, not speaking for, AS&M Inc, at NASA LaRC, Hampton VA 23665-5225
Volume-Number: Volume 27, Number 34
From std-unix-request@uunet.UU.NET Thu Mar 19 18:39:58 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15419; Thu, 19 Mar 92 18:39:58 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23914; Thu, 19 Mar 92 18:39:47 -0500
Newsgroups: comp.std.unix
From: Scott Thomas <sthomas@mitchell.hac.com>
Subject: Summary of XTI responses
Message-Id: <1992Mar19.232505.9514@uunet.uu.net>
Originator: sef@ftp.UU.NET
Keywords: XTI TLI
Nntp-Posting-Host: ftp.uu.net
Reply-To: Scott Thomas <sthomas@mitchell.hac.com>
X-Submissions: std-unix@uunet.uu.net
Organization: Hughes Aircraft Company
Date: Thu, 19 Mar 1992 21:31:26 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sthomas@mitchell.hac.com (Scott Thomas)
Hello,
A while back I posted a request for info on X/Open's XTI API
standard. I apologize for the delay in posting this, but we
have other deadlines. The responses were not as plentiful
as I had hoped, but the few I did receive were helpful. Many
thanks to Joel Spencer of Bull Worldwide Information Systems,
who was especially helpful.
--
Scott Thomas
Space & Communications Group
Hughes Aircraft Co.
(fax) 703-438-8430
(email) proto@mitchell.eos.scg.hac.com
-------------------- cut here --------------------------------
From: jspencer@cass.ma02.bull.com (Joel Spencer)
Subject: Re: X/Open's XTI standard & OSF's TLI standard
Newsgroups: comp.std.unix
Organization: Bull World Wide Information Systems Inc.
( Joel Spencer faxed a copy of the DPX & DPX/2 reference manual
appendix from BULL Info. Systems. The appendix briefly discusses
the differences between XTI & TLI. Below is a short summary of
the appendix, most of which I quoted. )
XTI is based on the SVID Issue 2, Volume 3, Networking
Services Extensions. XTI provides refinement of the Transport
Level Interface where such refinement is considered necessary.
This refinement includes:
- additional commentary ...
- modifications to the interface ...
- removal of dependencies on specific UNIX verisons ...
The following features can be considered XTI extensions to TLI:
- Some functions may return more error types ...
- transport provider identifier has been generalised ...
- additional events have been defined ...
- additional features added to t_snd(), t_sndrel(), t_rcvrel()
- can use options for certain types of transport service
- O_RDONLY & O_WRONLY flags usage withdrawn
- XTI checks value of 'qlen' and prevents applications
waiting forever on 't_listen()' calls
( Joel also answered a few questions, which I included the responses to. )
>>
>> Does the document mention how to obtain XTI? If not, could you please
>> tell me? As a user, do you prefer XTI over TLI?
>>
>
> i do not think that XTI is a public domain item. certainly the stuff that
> i work on is an "orderable" item with a market id(CNDG001-CB00) and a
> price. the documentation set is also a separately orderable
> item. i do not know who your UNIX vendors are, but you may be able
> to oreder a copy of XTI from them. then again, from feedback that
> i have gotten, the Bull UNIX XTI release is one of the first available.
>
> as a user i prefer XTI. the documentation is better. and i know it will
> be around for a while because it is sanctioned by X/Open. i do not
> think TLI will have as many users as XTI. but only time will tell.
>
========================================================================
From: sp@gr.osf.org (Simon Patience)
Subject: Re: X/Open's XTI standard & OSF's TLI standard
One piece of information for you. The TLI interface is in fact a product of
AT&T and not OSF. It is what X/Open based XTI (which OSF supports) on.
Simon.
Simon Patience
Open Software Foundation Phone: +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
========================================================================
From: mfc@medoc.aux.apple.com (Matthew Caprile)
Subject: X/Open's XTI standard & OSF's TLI standard
XTI is described in voume 7 of the X/Open Portability Guide, issue 3 (XPG3).
The ISBN number is 0-13-685892-9. You can walk into any decent bookstore
and have them order it (it is published by Prentice Hall). Or you can go
to a computer-specialist bookstore and ask them if they have it in stock.
It is supposed to be a transport-level independant networking interface
(You are supposed to be able to write apps that will work over both
ISO and TCP/IP stacks, not caring which one is used).
You might want to contact X/Open directly to see if they have published
anything on XTI since XPG3 came out.
X/Open Company Limited
Apex Plaza, Forbury Road
Reading, England, RG1 1AX
Tel: +(44) (0)734 508311 x2230
-or-
X/Open Company Ltd
1010 El Camino Real, Suite 380
Menlo Park, CA 94025
Phone: +1 415 323-7992
FAX: +1 415 323-8204
========================================================================
Volume-Number: Volume 27, Number 35
From std-unix-request@uunet.UU.NET Fri Mar 20 18:22:44 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13023; Fri, 20 Mar 92 18:22:44 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12249; Fri, 20 Mar 92 18:22:35 -0500
Newsgroups: comp.std.unix
From: "Brian R. Haug" <brian.haug@ncrcae.columbiasc.ncr.com>
Subject: seekdir/rewinddir on non seekable file systems
Message-Id: <1992Mar20.225009.29556@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: NCR Corp
Date: Fri, 20 Mar 1992 22:12:58 GMT
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: brian.haug@ncrcae.columbiasc.NCR.COM ("Brian R. Haug")
I've recently encountered a problem with seekdir in that it does not work
when the directory is on a device incapable of seeking (like the /dev/fd
filesystem in SVR4) because seekdir calls lseek which fails. I realize that
seekdir is no part of POSIX, but we have to be compatible with SVID and X/OPEN
too.
Basicly, I'm interested in hearing what other people think about this "problem."
POSIX seems to have done a good job covering all the bases, as it does not
allow chroot, which would prevent re-opening the file to implement rewinddir.
Unfortunately, SVID and X/OPEN allow chroot. And, of course, neither
rewinddir nor seekdir returns values to indicate failure.
Comments about the standard, problem, or proposed solutions would be greatly
appreciated.
Share and Enjoy!
Brian
Volume-Number: Volume 27, Number 36
From std-unix-request@uunet.UU.NET Sat Mar 21 18:53:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA29562; Sat, 21 Mar 92 18:53:32 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA02840; Sat, 21 Mar 92 18:53:22 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <karish@mindcraft.com>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <1992Mar21.232333.20048@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Mar20.225009.29556@uunet.uu.net>
Date: Sat, 21 Mar 1992 19:31:46 GMT
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 article <1992Mar20.225009.29556@uunet.uu.net>
brian.haug@ncrcae.columbiasc.NCR.COM ("Brian R. Haug") writes:
>I've recently encountered a problem with seekdir in that it does not work
>when the directory is on a device incapable of seeking (like the /dev/fd
>filesystem in SVR4) because seekdir calls lseek which fails.
Then I guess you'll have to convert the directory into a seekable
form, perhaps by copying it into memory.
>POSIX seems to have done a good job covering all the bases, as it does not
>allow chroot, which would prevent re-opening the file to implement rewinddir.
If you cache the directory, all it takes is a pointer assignment.
POSIX doesn't require that you maintain cache consistency on
the directory image, either.
Are you saying that SVID and XPG3 require that an open directory
stream remain useful after a call to chroot() that would make
the directory itself inaccessible?
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 27, Number 37
From std-unix-request@uunet.UU.NET Mon Mar 23 18:27:24 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24983; Mon, 23 Mar 92 18:27:24 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21365; Mon, 23 Mar 92 18:27:16 -0500
Newsgroups: comp.std.unix
From: "Brian R. Haug" <haug@grok20.columbiasc.ncr.com>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <1992Mar23.224851.13912@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: NCR Corp
References: <1992Mar20.225009.29556@uunet.uu.net> <1992Mar21.232333.20048@uunet.uu.net>
Date: Mon, 23 Mar 1992 14:10:06 GMT
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: haug@grok20.columbiasc.NCR.COM ("Brian R. Haug")
In article <1992Mar21.232333.20048@uunet.uu.net> karish@mindcraft.com
(Chuck Karish) writes:
>In article <1992Mar20.225009.29556@uunet.uu.net> I wrote
>>I've recently encountered a problem with seekdir in that it does not work
>>when the directory is on a device incapable of seeking (like the /dev/fd
>>filesystem in SVR4) because seekdir calls lseek which fails.
>
>Then I guess you'll have to convert the directory into a seekable
>form, perhaps by copying it into memory.
This was considered, but was not acceptable for two reasons:
1) rewinddir is implemented as a call to seekdir, and POSIX requires
rewinddir to "refer to the current state of the corresponding
directory, as a call to opendir() would have done." See 5.1.2.2
lines 51-54. This puts me back at square one again with regard
to seeking. I probably should have made the rewinddir point
better in my original post.
2) The directory could be huge, allocating a megabyte, or even several K
of memory was deemed inappropriate for our implementation.
>>POSIX seems to have done a good job covering all the bases, as it does not
>>allow chroot, which would prevent re-opening the file to implement rewinddir.
>
>If you cache the directory, all it takes is a pointer assignment.
>POSIX doesn't require that you maintain cache consistency on
>the directory image, either.
Unless I've mis-understood what you're saying here, I have to disagree, see
the section of the standard mentioned earlier.
>Are you saying that SVID and XPG3 require that an open directory
>stream remain useful after a call to chroot() that would make
>the directory itself inaccessible?
That's my interpretation. Granted you can not open any of the files
that you find in that directory, but I should still be able to access
the directory (until closedir is called). After all, I can access files
not available from the current root directory IF I had them open before
the chroot call. Seems like the same idea to me.
Knowing your reputation, I appreciate you taking time to respond. I
think you've helped me better explain the problems we perceive.
Volume-Number: Volume 27, Number 38
From std-unix-request@uunet.UU.NET Tue Mar 24 00:01:54 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04780; Tue, 24 Mar 92 00:01:54 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23482; Tue, 24 Mar 92 00:01:43 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <1992Mar24.042302.25869@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <1992Mar20.225009.29556@uunet.uu.net>
Date: Tue, 24 Mar 1992 03:59:52 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1992Mar20.225009.29556@uunet.uu.net> brian.haug@ncrcae.columbiasc.NCR.COM ("Brian R. Haug") writes:
>I've recently encountered a problem with seekdir in that it does not work
>when the directory is on a device incapable of seeking (like the /dev/fd
>filesystem in SVR4) because seekdir calls lseek which fails. I realize that
>seekdir is no part of POSIX, but we have to be compatible with SVID and X/OPEN
>too.
I was intimately involved in the 1003.1 specification for the directory
access functions, and also implemented a widely used more-or-less portable
version of these functions (including seekdir()/telldir()) that among
other things served as the basis of the version shipped with UNIX System V.
I mention this to assure you of my familiarity with the problems..
The reason that 1003.1 did NOT specify seekdir()/telldir() is that there
simply is no way to guarantee that these can be correctly implemented in
all reasonable environments. All versions I have seen (including mine)
depend on filesystem behavior that is by no means guaranteed, and as you
have discovered this problem has gotten worse as evolution has proceeded.
My copies of SVID and XPG are not at hand as I write this, but if they are
currently insisting on reliable seekdir()/telldir() they need to be fixed.
rewinddir() is more important, because it IS required by 1003.1. The only
way I know of to implement it on a system that doesn't support lseek() to
the beginning (only!) of an open directory is to record the full pathname
at opendir() time and use this information to reopen the directory (after
closing the current fd). As you observe, chroot() could cause this to
fail, which is not a problem for POSIX but would be for other UNIX
standards. Are you sure that /dev/fd cannot be lseek()ed even to its
beginning? That would seem to be a severe deficiency in the implementation
of that filesystem. Assuming /dev/fd cannot be fixed, then I'd suggest
that SVID/XPG/etc. exempt rewinddir() from being used (in conforming
applications) after a chroot(). (chroot() opens a large can of worms, and
might be better left out of UNIX application interface standards.)
Volume-Number: Volume 27, Number 39
From std-unix-request@uunet.UU.NET Wed Mar 25 17:23:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10086; Wed, 25 Mar 92 17:23:42 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29763; Wed, 25 Mar 92 17:23:38 -0500
Newsgroups: comp.std.unix
From: "Brian R. Haug" <haug@grok20.columbiasc.ncr.com>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <1992Mar25.220739.18347@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: NCR Corp
References: <1992Mar20.225009.29556@uunet.uu.net> <1992Mar24.042302.25869@uunet.uu.net>
Date: Wed, 25 Mar 1992 21:39:03 GMT
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: haug@grok20.columbiasc.NCR.COM ("Brian R. Haug")
In article <1992Mar24.042302.25869@uunet.uu.net> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
>
>rewinddir() is more important, because it IS required by 1003.1. The only
>way I know of to implement it on a system that doesn't support lseek() to
>the beginning (only!) of an open directory is to record the full pathname
>at opendir() time and use this information to reopen the directory (after
>closing the current fd).
A co-worker suggested that perhaps the real problem is that rewinddir and
seekdir are of type void and should have some other type so that they may
return an error condition (like the one I'm having to deal with).
When Andy Tannenbaum (sp?) remarked "Standards are wonderful, there are so
many to choose from." He obviously was not in the implementor's shoes!
Share and Enjoy!
Brian
Volume-Number: Volume 27, Number 40
From std-unix-request@uunet.UU.NET Wed Mar 25 19:20:47 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA14922; Wed, 25 Mar 92 19:20:47 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA01557; Wed, 25 Mar 92 19:20:45 -0500
Newsgroups: comp.std.unix
From: Johann Haider <jh@fortec.tuwien.ac.at>
Subject: awk should deal with hexadecimal numbers
Message-Id: <1992Mar25.233157.27088@uunet.uu.net>
Summary: awk is lacking functionality to deal with numbers other than decimal
Originator: sef@ftp.UU.NET
Keywords: awk posix hexadecimal
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Technical University of Vienna
Date: Wed, 25 Mar 1992 22:16:42 GMT
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: jh@fortec.tuwien.ac.at (Johann Haider)
Hello all,
I read in the distribution of Mawk that there is a posix draft
( posix1003.2 draft(11.2) ) of awk, therefore I hope this article
isn't totally misplaced :-)
After I had used awk for some time some years ago I had the problem
to parse the output of `nm' which is in hexadecimal on that platform.
I had to write a filter program in C to convert the hex addresses to
decimal and do the parsing afterwards.
When Gnu awk came along I addeed a new function strtol() to convert
arbitrary base numbers to decimal.
As I consider this function very useful, I think it should be added to
the standard or at least it should not be omitted from the standard
without being discussed.
If someone is in the posix comitee and such a function has been abandoned
already I would be glad to hear about it.
Thank you
Hans
--
Johann Haider Rehabilitation Engineering Group
Institute for Electronics Technical University Vienna, Austria
Email: jh@fortec.tuwien.ac.at phone: +431 58801 3967
[ In general, comp.std.unix (or the std-unix-list mailing list) is not
the right place to work on the POSIX standard(s). It is a good place
for *discussion*, however, which is why I've posted this. -- mod ]
Volume-Number: Volume 27, Number 41
From std-unix-request@uunet.UU.NET Thu Mar 26 16:27:01 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA23823; Thu, 26 Mar 92 16:27:01 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA14358; Thu, 26 Mar 92 16:26:57 -0500
Newsgroups: comp.std.unix
From: Bob Robillard <duke@sunni.ctsd.bellcore.com>
Subject: Call for Input for 1003.7
Message-Id: <1992Mar26.205916.17238@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Thu, 26 Mar 1992 20:18:36 GMT
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: duke@sunni.ctsd.bellcore.com (Bob Robillard)
[ Responses can go to Jeff Parker or to the poster, Bob Robillard
(duke@cc.bellcore.com) ]
I'm writing on behalf of POSIX 1003.7. We are looking for examples
of existing practice in User and Group Management, and we would like to
invite your company to submit either existing products or requirements.
We are hope to describe an API for distributed user management, but we
would be happy to consider existing practice that illuminates the problem.
Our next meeting is in Dallas the week of April 6-10th. I will convey
any documents that reach me before then. We also welcome any representation
you may be able to provide.
Jeff Parker, POSIX 1003.7, Sun Microsystems
Jeff.Parker@east.sun.com
Volume-Number: Volume 27, Number 42
From std-unix-request@uunet.UU.NET Fri Mar 27 23:47:48 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA21455; Fri, 27 Mar 92 23:47:48 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18907; Fri, 27 Mar 92 23:47:55 -0500
Newsgroups: comp.std.unix
From: rabin@osf.org
Subject: P1003.4[a] Common Reference Ballots (CRBs)
Message-Id: <1992Mar27.212634.11619@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Fri, 27 Mar 1992 15:27:24 GMT
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: rabin@osf.org
Please be advised that this week a small group of people from
OSF, USL and other organizations met and drafted the CRBs
for P1003.4 (Realtime) and P1003.4a (pthreads). The .4 CRB
will be published Tuesday March 31st and the .4a CRB will
be published Monday April 13th. Ballots are due at the IEEE
office April 8th and May 1st respectively.
The CRB represents a consensus of the CRB group and we hope you
will read and consider endorsing the objections submitted in the CRBs.
Thanks Much.
Volume-Number: Volume 27, Number 43
From std-unix-request@uunet.UU.NET Sat Mar 28 08:42:27 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA23024; Sat, 28 Mar 92 08:42:27 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA09449; Sat, 28 Mar 92 08:42:29 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <henry@zoo.toronto.edu>
Subject: Re: awk should deal with hexadecimal numbers
Message-Id: <1992Mar28.093842.11910@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: U of Toronto Zoology
References: <1992Mar25.233157.27088@uunet.uu.net>
Date: Fri, 27 Mar 1992 21:18:29 GMT
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)
>Submitted-by: jh@fortec.tuwien.ac.at (Johann Haider)
>As I consider this function very useful, I think it should be added to
>the standard or at least it should not be omitted from the standard
>without being discussed.
It is, unfortunately, rather too late for this. 1003.2, which covers
awk among many other things, is pretty much finalized.
It *is* a blemish that awk can do various kinds of conversions *to*
strings using sprintf, but can't go the other way very easily.
--
GCC 2.0 is to C as SVR4 is to Unix. | Henry Spencer @ U of Toronto Zoology
-Dick Dunn | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 27, Number 44
From std-unix-request@uunet.UU.NET Sat Mar 28 08:42:31 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA23031; Sat, 28 Mar 92 08:42:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA09461; Sat, 28 Mar 92 08:42:32 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: seekdir/rewinddir on non seekable file systems
Message-Id: <1992Mar28.094023.12123@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <1992Mar20.225009.29556@uunet.uu.net> <1992Mar24.042302.25869@uunet.uu.net> <1992Mar25.220739.18347@uunet.uu.net>
Date: Fri, 27 Mar 1992 17:05:50 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1992Mar25.220739.18347@uunet.uu.net> haug@grok20.columbiasc.NCR.COM ("Brian R. Haug") writes:
>A co-worker suggested that perhaps the real problem is that rewinddir and
>seekdir are of type void and should have some other type so that they may
>return an error condition (like the one I'm having to deal with).
I agree that it was unfortunate, but it wouldn't solve the REAL problem
(from the point of view of the application program), which is that the
rewinddir() fails under perfectly ordinary usage. As I recall the P1003
discussions, the opinion was generally held that if opendir() succeeded,
then a subsequent rewinddir() couldn't possibly fail (except if the
filesystem went off line or something of the sort, which we weren't
particularly concerned about at the time). seekdir(), on the other hand,
was expected to malfunction using any reasonable user-mode implementation,
on certain systems that dynamically compact directories. (Of course they
would also affect readdir(), but only in the sense of causing some entries
to be skipped. Really, the file-system part of the operating system should
provide more reliable directory access facilities than UNIX typically does.)
My honest suggestion is to get the /dev/fd filesystem maintainer to support
seeking to BOF at least, if not providing seek in its full generality.
Volume-Number: Volume 27, Number 45
From std-unix-request@uunet.UU.NET Mon Mar 30 20:18:20 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA12153; Mon, 30 Mar 92 20:18:20 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24374; Mon, 30 Mar 92 20:18:27 -0500
Newsgroups: comp.std.unix
From: Arnold Robbins <arnold@cc.gatech.edu>
Subject: 1003.2a on comments in the shell
Message-Id: <1992Mar30.205758.2699@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
Reply-To: arnold@cc.gatech.edu
X-Submissions: std-unix@uunet.uu.net
Organization: Georgia Institute of Technology
Date: Mon, 30 Mar 1992 14:59:47 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: arnold@cc.gatech.edu (Arnold Robbins)
Could someone familiar with 1003.2a (the UPE - User Portability Extension)
answer the following question for me?
What does
echo a # b c
produce if typed at an interactive shell? There is one sh-style shell out
in the wide world that will echo 'a # b c' instead of just 'a' and I'd like
to know if this behavior is POSIX-compiliant.
Thanks,
--
Arnold Robbins --- College of Computing | Laundry increases
Georgia Tech, Atlanta, GA 30332-0280 | exponentially in the
Domain: arnold@cc.gatech.edu Phone: +1 404 894 9214 | number of children.
UUCP: uunet!cc.gatech.edu!arnold FAX: +1 404 853 9378 | -- Miriam Robbins
Volume-Number: Volume 27, Number 46
From std-unix-request@uunet.UU.NET Mon Mar 30 22:26:35 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17403; Mon, 30 Mar 92 22:26:35 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22482; Mon, 30 Mar 92 22:26:43 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <djm@eng.umd.edu>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Mar31.024454.23050@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Project GLUE, University of Maryland
References: <1992Mar30.205758.2699@uunet.uu.net>
Date: Tue, 31 Mar 1992 02:09:13 GMT
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: djm@eng.umd.edu (David J. MacKenzie)
> Could someone familiar with 1003.2a (the UPE - User Portability Extension)
> answer the following question for me?
> What does
> echo a # b c
> produce if typed at an interactive shell? There is one sh-style shell out
> in the wide world that will echo 'a # b c' instead of just 'a' and I'd like
> to know if this behavior is POSIX-compiliant.
The only explicit mention of `#' for the shell in p1003.2a is in the
description of the Vi editing mode. It's a command to comment-out the
current line (excerpted below). Read strictly, it doesn't appear to
say anything about what happens when the user types a `#' as part of a
command, only what happens when the shell inserts a `#' in response to
a special command. Read more loosely, it requires that `#' at the
beginning of a line begin a comment, but doesn't explicitly say
anything about `#' in the middle of a line. Read more loosely still,
it specifies that `#' introduces a comment in interactive shells.
Perhaps I missed an implicit or blanket reference somewhere to how
non-interactive comments affect interactive shells, which would affect
the above analysis. If not, POSIX.2a doesn't precisely say whether or
not that shell's behavior is compilant, so I suppose that it is.
4.56.7.5 Vi Line Editing Command Mode
. . .
The following commands shall be recognized in command mode:
. . .
# Insert the character # at the beginning of the current
command line and treat the current command line as a
comment. This line shall be entered into the command 8
history; see 5.12. 8
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
Volume-Number: Volume 27, Number 47
From std-unix-request@uunet.UU.NET Tue Mar 31 15:53:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA18365; Tue, 31 Mar 92 15:53:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29086; Tue, 31 Mar 92 15:53:07 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Mar31.204813.684@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net>
Date: Tue, 31 Mar 1992 11:27:37 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1992Mar31.024454.23050@uunet.uu.net> djm@eng.umd.edu (David J. MacKenzie) writes:
>The only explicit mention of `#' for the shell in p1003.2a is in the
>description of the Vi editing mode. It's a command to comment-out the
>current line (excerpted below). ...
That's disgusting!
If 1003.2 is going to break zillions of existing carefuly-written shell
scripts, then it ought not to be adopted.
Volume-Number: Volume 27, Number 48
From std-unix-request@uunet.UU.NET Tue Mar 31 15:53:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA18366; Tue, 31 Mar 92 15:53:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29048; Tue, 31 Mar 92 15:53:02 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <mks!stephe>
Subject: EurOpen Report on POSIX, Jan '92
Message-Id: <1992Mar31.204858.886@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Tue, 31 Mar 1992 16:33:45 GMT
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: stephe@mks.uucp (Stephen Walli)
Report on the January 1992 IEEE POSIX Meeting for EurOpen
Stephen R. Walli <stephe@mks.com>
EurOpen Institutional Representative
Standing on Huntington Beach, gazing across the moonlit
Pacific after a five hour Sponsor Executive Committee
meeting, is a small group of POSIX refugees. It is 10 pm.
The oil rigs glow golden in the distance like great
Christmas trees. The surf crashes and hisses at our feet.
Jason: Just remember, Stephe, in the grand scheme of
things....
Stephe [interrupting]: ...Oil's important.
Okay. So I'm a cynic. It was generally an ugly week. I
believe there are still some fundamental flaws in the
structure of POSIX. Working group members are still
grappling with the enormity of the beast we've created.
GUIs, rescued from the jaws of defeat by the IEEE Standards
Advisory Board, entered the scene again. Life (and POSIX)
goes on.
1. POSIX is coming! POSIX is coming!
The IEEE POSIX working groups ARE coming to Europe. This
Autumn, the POSIX working groups will be meeting in Utrecht,
NL, from October 19-23. The meetings will be held at the
Holiday Inn and the Scandic Crown Hotel.
Information will be posted to this column, and on the net
where appropriate, as the meetings approach.
There will also be an ISO Working Group 15 (WG15 -- ISO
POSIX) meeting around the same time. It will either be the
week before or the week after, and will also be in Europe.
Again, information will be forthcoming.
2. SICC and the PMC
POSIX often makes use of the fact that a small group of
people can go off and accomplish what a large group will
spend hours arguing about. Small committees are the work
method of choice in many areas. Two committees of the
Sponsor Executive Committee (SEC) are the System Interfaces
Co-ordination Committee (SICC), and the Project Management
Committee (PMC).
SICC is gaining momentum. It is effectively the chairs of
all the system interface groups:
-- POSIX.1, the base system interface,
-- POSIX.4, real-time extensions to POSIX.1,
-- POSIX.6, security extensions to POSIX.1,
-- POSIX.8, transparent file access extensions to POSIX.1,
-- POSIX.12, protocol independent interfaces (Berkeley
sockets and X/Open's TLI).
-- POSIX.15, supercomputing batch interfaces,
-- POSIX.17, directory services (think X.500).
They are a simple subcommittee of the SEC, that meets to
resolve areas of conflict between the base standards, and to
work out concerns which affect all of the documents.
The other group which is effecting the way POSIX is coming
forward is the Project Management Committee (PMC). This was
the fourth meeting the PMC has existed, and half of its
eight members were due to retire. Two elected to stay on
(and were voted back in by the SEC) for an additional two
year term. Two new members (one of them the EurOpen
Institutional Representative,) were also voted into the
group.
The PMC is responsible for mentoring existing projects to
ensure they are performing according to plan. They are also
responsible for ensuring that new project requests (PARs)
are complete and have all the attendant paper work before
reaching the SEC.
One interesting result of their work this week was the
splitting up of the POSIX.7 (System Administration) project.
POSIX.7 has been re-organized into:
-- a parent project (POSIX.7), which is responsible for co-
ordinating the other parts of the POSIX.7 standard
-- POSIX.7a to build a standard for print management,
-- POSIX.7b to build a standard for software management,
-- POSIX.7c to a set of guidelines for user management.
The final subproject is important. There is not sufficient
agreement on how to do user administration to build a
standard. There is a lot of existing practice with
administering users. Everyone agrees that the current
solutions are not good. So they are building a set of agreed
upon guidelines. It's really too bad the PMC didn't exist
when other project requests were cut to suggest this sort of
solution for certain other contentious immature areas of
technology.
3. Multi-lingual Test Assertions
Multi-lingual Test Assertions are test assertions written in
such a way that test suites in multiple programming
languages could be written. This addresses the problems
associated with testing conformance for something like an
Ada run-time environment, that supports POSIX.5 (the Ada
language version of POSIX.1 functionality,) when all the
test suites are written in C.
POSIX describes an interface to operating system services.
It is based on the historical C interface to UNIX, but
should not be restricted to just that language. No one
wants to make the same mistakes made with GKS (which
demonstrated you could write Fortran programs in any
language,) by forcing other languages to bind the interfaces
in the same functional way.
This was why ISO WG15 (ISO POSIX) wants a programming
language independent specification to be written of POSIX.1.
Other languages can then bind the functionality
appropriately. The semantic description would be kept in a
single book, with the appropriate syntactic binding and glue
in other books.
Test assertions written to POSIX.1 demonstrate the same
problems. Everyone agrees that much of the functional
content of the test methods for POSIX.1 should be the same
no matter what programming language is being used to write
the suite. If the test assertions from which the test cases
are built were written to the programming language
independent version of the standard, they could be bound to
the language syntax at the same time as the functional
specification, providing a language based set of assertions
from which to build the conformance test suite.
Okay. The cat's out of the bag. We are really discussing
language independent specification test assertions. If I
used that as the title to this section, you might have
turned the page. Hopefully, you now at least appreciate the
problem to be solved, even if you still run screaming into
the night.
Now all we have to do is solve the resource problem, and
find people to help with the specification.
4. Distributed Security Study Group
A group of about twenty people met for a day during the
January POSIX meeting to discuss distributed security
technologies and scenarios. The group felt it had sufficient
momentum and manpower to form a proper study group, and they
will meet for the entire week at the April meeting in
Dallas, TX.
They were a little disorganized to begin with, but agreed to
a set of existing specifications and models they wish to
begin investigating at the next meeting.
There are those within the group that wish to take some time
to investigate the current base of experience before
proceeding, while others appear to want to pick a
specification and begin tweaking it into a standard. Pretty
aggressive considering they haven't cut a project request
yet!
5. PAR Wars II -- The Umpire Strikes Back
Since we last looked in on our story, our protagonists,
OSF/Motif and Open Look (sometimes known as Rodan and
Godzilla) were off chasing their project requests (PARs) up
the IEEE Standards hierarchy. Having been told ``no'' by the
Sponsor Executive Committee (SEC), they are now asking for
sponsorship at the higher level of the IEEE Standards
Advisory Board (SAB).
You will recall the flow.
-- April 1991, the PARs first surface. The intent is to
directly form ballot groups to ballot the current
programmers and users guides. The SEC, clearly
uncomfortable with the obvious overlap between these two
GUI PARs and the current work in P1201, argues for several
hours (!) and then tables discussion at that time.
-- July 1991, discussion is re-opened. A small committee is
formed to clearly state all pros and cons of the two
projects. The presentation is made, and since all members
of the SEC find at least one serious problem with the
Motif and Open Look project requests, the projects are
voted down.
Some were concerned over the apparent lack of maturity of
the technology. No one that has tried the two
technologies (with the exception of the PAR presenters)
seems to like either of the interfaces. People are
concerned that wrapping a standard around them now will
prevent them from being improved and matured. Some user
representatives clearly wish there to be a single unified
standard.
With the apparent ``death'' of the two competing PARs came
a motion to remove sponsorship from the existing P1201
project, arguing it suffers the same flaws. Discussion is
tabled to the project management committee (PMC) until
October.
-- October 1991, P1201 is allowed to survive. P1201.1 is
making good progress at defining a higher level interface
for simple windowing, based on current practice. While
possibly not as functional as either the Motif or Open
Look toolkits, it is useful to a wide range of
applications, and there is consensus forming around it.
P1201.2 is preparing a recommended practice document on
windowing style, and is making good progress.
The Motif and Open Look projects presenters are off
haunting other corridors (SAB). The SAB, pointing to the
802 LAN standards as if they were a ``good'' example, has
said it is an insufficient reason to kill the project
requests simply because they have overlapping scopes.
The SEC is responsible for approving projects for the IEEE
Technical Committee on Operating Systems -- Standards
Subcommittee (TCOS-SS). This is where POSIX and the GUI
standards all reside.
It seems the SAB is sympathetic to their plight and has
agreed to sponsor the projects. Gone are the contentious
ideas that the two camps will directly form ballot groups
and ballot the current programmers references and users
guides. The SAB has said that they must play fair, and play
by the rules. (Direct balloting only exists on paper as a
method of fast-tracking clearly uncontentious documents.)
The SAB has further offered them BACK to TCOS-SS/SEC! The
projects really DO belong within the scope of TCOS. The SEC
agreed to take a look at the revised sponsored-in-principle
projects at the April 1992 meeting. I believe one member's
phrase was to ``accept the pig in a poke now, and rip the
bag off later.'' Hopefully, it won't be too prophetic an
analogy.
We have been cautioned that we can not trivially agree to
accept them, then shut them down. They have been sponsored-
in-principle by a higher power. The two projects have
already each held their first meetings, outside of TCOS's
sphere of influence.
I for one want to see them really play by the rules! If
accepted by TCOS, they should certainly come into the
Steering Committee on Windowing User Interfaces (SCWUI)
realm of influence. No reason to exempt them from test
assertions either.
Language independent specifications (LIS) are certainly
appropriate considering the number of Ada developers that
currently need to find messy solutions to working with these
two GUIs in their native Ada environments. Indeed, they may
discover that they functionally overlap more than they care
to admit by writing the LIS. If they rationalize the LIS,
as POSIX.12 is doing with C-based sockets and C-based XTI,
then maybe Ada could benefit by coming up with a single
binding standard!
Of course, if they were to come forward as recommended
practices or guidelines, instead of as full use standards,
they would not need to provide LIS and test assertions as
robustness proofs. Something to think about.
As I said at the end of the last report, ``thus are
standards born.''
Volume-Number: Volume 27, Number 49
From std-unix-request@uunet.UU.NET Tue Mar 31 16:26:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA22174; Tue, 31 Mar 92 16:26:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07916; Tue, 31 Mar 92 16:26:24 -0500
Newsgroups: comp.std.unix
From: Peter da Silva <peter@ferranti.com>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Mar31.212031.4967@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Xenix Support, FICC
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net>
Date: Tue, 31 Mar 1992 15:51:40 GMT
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)
What is P1003.2a doing specifying the behaviour of vi-mode command line
editing in the first place? Is it specifying that "the shell" be ksh?
[ Or bash -- mod ]
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
Volume-Number: Volume 27, Number 50
From std-unix-request@uunet.UU.NET Wed Apr 1 21:58:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26676; Wed, 1 Apr 92 21:58:47 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28406; Wed, 1 Apr 92 21:58:55 -0500
Newsgroups: comp.std.unix
From: Chet Ramey <chet@odin.ins.cwru.edu>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Apr2.024730.26729@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Case Western Reserve University
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net> <1992Mar31.212031.4967@uunet.uu.net>
Date: Tue, 31 Mar 1992 22:53:07 GMT
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: chet@odin.INS.CWRU.Edu (Chet Ramey)
In article <1992Mar31.212031.4967@uunet.uu.net> peter@ferranti.com (Peter da Silva) writes:
>What is P1003.2a doing specifying the behaviour of vi-mode command line
>editing in the first place? Is it specifying that "the shell" be ksh?
Yes, to a degree. 1003.2a specifies a subset of ksh. The `base document'
is Bolsky & Korn's book. The term `only one historical implementation' is
used frequently. Things are specified exactly as ksh implements them.
Here's a sample quote:
``The KornShell version was adopted to be consistent with all the other
KornShell features in POSIX.2, such as command-line editing.''
Chet
--
``The use of history as therapy means the corruption of history as history.''
-- Arthur Schlesinger
Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu
Volume-Number: Volume 27, Number 51
From std-unix-request@uunet.UU.NET Wed Apr 1 21:58:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26683; Wed, 1 Apr 92 21:58:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28426; Wed, 1 Apr 92 21:58:59 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <djm@eng.umd.edu>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Apr2.024822.26879@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Project GLUE, University of Maryland
References: <1992Mar30.205758.2699@uunet.uu.net>
Date: Wed, 1 Apr 1992 05:25:32 GMT
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: djm@eng.umd.edu (David J. MacKenzie)
> Perhaps I missed an implicit or blanket reference somewhere to how
> non-interactive comments affect interactive shells, which would affect
> the above analysis. If not, POSIX.2a doesn't precisely say whether or
> not that shell's behavior is compilant, so I suppose that it is.
It appears that I did miss something -- any behavior that P1003.2a
doesn't specify as being different for interactive operation is the
same as for non-interactive operation. So interactive comments need
to work the same way as non-interactive comments. In other words,
"that shell" (bash) doesn't comply with 1003.2a in its handling of
interactive comments.
Sorry for my hasty analysis.
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
Volume-Number: Volume 27, Number 52
From std-unix-request@uunet.UU.NET Wed Apr 1 21:58:58 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26692; Wed, 1 Apr 92 21:58:58 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28458; Wed, 1 Apr 92 21:59:05 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <djm@eng.umd.edu>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Apr2.024908.27038@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Project GLUE, University of Maryland
References: <1992Mar30.205758.2699@uunet.uu.net>
Date: Wed, 1 Apr 1992 05:28:18 GMT
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: djm@eng.umd.edu (David J. MacKenzie)
>>The only explicit mention of `#' for the shell in p1003.2a is in the
>>description of the Vi editing mode. It's a command to comment-out the
>>current line (excerpted below). ...
> That's disgusting!
> If 1003.2 is going to break zillions of existing carefuly-written shell
> scripts, then it ought not to be adopted.
Don't worry, no shell scripts are in danger (at least for this reason).
We're talking about 1003.2a, the User Portability Extension, here, not
the base 1003.2 standard. 1003.2 does specify traditional post-v7
Bourne behavior for comments in shell scripts. The question was, does
1003.2a specify the same behavior for interactive use. It appears
that it does.
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
Volume-Number: Volume 27, Number 53
From std-unix-request@uunet.UU.NET Wed Apr 1 21:59:02 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26706; Wed, 1 Apr 92 21:59:02 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28498; Wed, 1 Apr 92 21:59:09 -0500
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <djm@eng.umd.edu>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Apr2.024953.27215@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: Project GLUE, University of Maryland
References: <1992Mar30.205758.2699@uunet.uu.net>
Date: Wed, 1 Apr 1992 05:29:49 GMT
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: djm@eng.umd.edu (David J. MacKenzie)
> What is P1003.2a doing specifying the behaviour of vi-mode command line
> editing in the first place? Is it specifying that "the shell" be ksh?
There's been an ongoing battle during the drafting process between
those who want it to specify a Bourn-like shell and those who want a
Korn-like shell. The current draft is somewhere in between.
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
Volume-Number: Volume 27, Number 54
From std-unix-request@uunet.UU.NET Wed Apr 1 21:59:08 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26724; Wed, 1 Apr 92 21:59:08 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28520; Wed, 1 Apr 92 21:59:14 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on IEEE Standards Board, Dec. 1991
Message-Id: <1992Apr2.025040.27452@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:10 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
The IEEE Standards Board
An Anonymous Friend of USENIX reports on the December 3-5,
1991 meeting in New York, NY:
[ed. -_- The report writer asked to remain anonymous. Anyone
wishing to send comments to the writer may do so through
me.]
The IEEE Standards Board is the committee responsible for
overseeing all standards related activities within the IEEE.
The IEEE produces standards for the entire electrical
engineering spectrum, not just the Computer Society. The
Technical Committee on Operating Systems -- Standards
Subcommittee (TCOS-SS), is the IEEE Computer Society
committee responsible for the POSIX family of standards.
As usual, the December 1991 meetings of the IEEE Standards
Board produced a plethora of new Project Approval Requests
(PARs) and approved projects, some new rules to apply to the
standards process, and one more new Organizational
Representative that can ballot POSIX standards.
Acknowledgments
Perhaps the new rule that most impacts the IT community is
one concerning the use of acknowledgment sections in
standards. You've probably seen one of these sections
before; they're the ones that thank your
company/university/organization/mother for providing the
means for you to contribute your thoughts and ideas to that
lovely thing known as the standards process. It's usually
found in the front or back of the standard in what we
jargon-savvy folks know are informative sections of the
document, so it's not part of the official standard. (Don't
confuse it with the foreword or introduction, which discuss
the technical and historical development of the standard and
list the working group and balloting group.)
The IEEE Standards Board Procedures Committee (whew! that's
ProCom for short) felt that the IEEE could be legally liable
if the standards mentioned a company without first asking
their permission. A policy was proposed that said a working
group could include one of these sections if each member
obtained written permission from the companies/etc.
involved, to be kept on file with the IEEE Standards
Department. There are form letters for you to follow, but
nonetheless it's an extra step you'll have to take.
Of course, the question comes up as to whether you should be
doing this work at all. What if one company says yes and 20
say no? Do you have an acknowledgments section that only
lists a few companies? For a family of standards like
POSIX, should some standards have this section and some not?
As always, things rapidly get complicated. Because of this,
the POSIX technical editors had a lengthy discussion on
whether to have these sections at all in their documents.
Opinion was wide-ranging and varied; the interim decision
was to go to our individual working groups and ask for their
opinions. Based on those discussions, the technical editors
will decide whether to keep these sections in the future.
The Curse of Acronyms
As we all know, standards-writing groups have a seemingly
inexhaustible ability to create acronyms. Indeed, after a
while our conversations seem to consist entirely of
abbreviations, and woe betide the person who tries to
understand our arcane internal code.
Of course, the Standards Board has to do just that when they
look at our PARs, (oops! that's Project Authorization
Requests.) They understandably get frustrated. Because of
that, the New Standards Committee (NesCom) has said that
they don't want to see incomprehensible acronyms on PAR
submissions in the future. The NesCom members come from all
societies of the IEEE, not just Computer, and many power-
engineering standards developers can't begin to guess at
what an acronym means that you've used since the first time
you touched a keyboard.
This means we'll have to get used to standards titles that
are even longer than they are now! When filling out a PAR,
you'll have to remember to expand acronyms appropriately.
You wouldn't want to have the PAR rejected on these grounds.
This subject will be discussed in more detail at the next
NesCom meeting.
One Man, One Vote
Questions have arisen as to whether or not members such as
Institutional Representatives and similar reps in the power
engineering realm vote twice on a document, once as an
individual and possibly again representing their
organization. The Board agreed to appoint an ad hoc
committee to look at the issue of one man, one vote. More
information should be available from forthcoming meetings.
In other IR related news, SPARC is now officially approved
by the IEEE Standards Board as an IR and has the right to
vote on all POSIX documents.
[ed. -_- The following lists are provided, to allow the
reader to appreciate the full breadth of control the IEEE
Standards Board has as its mandate. These are still just the
Computer Society related standards. The reader should note
P1279, P1281, and P1282. Andrew Hume regularily warns in his
ANSI WORM standards reports that the WORM standards may have
a far broader impact than people think. Here, in P1282, we
even see them ``worming'' their way into POSIX.1 (ISO
9945-1).]
And here's the information on Review Committee (RevCom) and
NesCom Computer Society activity:
Approved New Computer Society PARs
P1278 (C/SCC) Standard for Information Technology-
Distributed Simulation Applications-Process and Data Entity
Interchange Formats
P1279 (C/SCC) Standard for Information Technology-CD-ROM
Architectural Profile
P1281 (C/SCC) Standard for Information Technology-Use of ISO
9660: 1988 System Use Fields
P1282 (C/SCC) Standard for Information Technology-
Interchange of ISO 9945-1:1990 Filesystems via the ISO 9660:
1988 File Structure
P802.1j (C/TCCC) Standard for Managed Objects for MAC
Bridges (Supplement of 802.1D)
P802.1k (C/TCCC) LAN/MAN Management Information for
Monitoring
and Event Reporting
P802.2C (C/TCCC) PICS Proforma for LLC Type 1 Operation and
LLC Type 2 Operation
P802.1D (C/TCCC) Technical and Editorial Corrections to Std.
802.1D
P802.2f (C/TCCC) Standard for LLC Sublayer Management
P802.6k (C/CC) Distributed Queue Dual Bus Subnet work of a
Metropolitan Area Network, Supplement for MAC Bridging
Revised Approved Computer Society PARs
P1209 (C/SE) Recommended Practice for the Evaluation and
Selection of CASE Tools
P802.1F (C/CC) Common Definitions and Procedures for 802
Management Information
P1155 (C/MM) Standard for VMEbus Extensions for
Instrumentation: VXIbus
P1175 (C/SCC) Trial Use Standard Reference Model for
Computing System Tool Interconnections
P1396 (C/MM) Standard for a Communication Bus (TELECOM Bus):
Reference Models
Withdrawn Computer Society PARs
P1101.5 (C/MM) Standard for Mechanical Core Specification
for Microcomputers-Desktop Form Factor
Approved New Computer Society Standards
610.6 (C/SCC) Standard Glossary of Computer Graphics
Terminology
1029.1 (SCC20 & C/DA) Standard for Waveform and Vector
Exchange (WAVES)
1175 (C/SCC) Trial Use Standard Reference Model for
Computing System Tool Interconnections
P1212 (C/MM) Standard Control and Status Register (CSR)
Architecture for Microcomputer Buses
Withdrawn Computer Society Standards
IEEE Std 662-1980, IEEE Standards Terminology for
Semiconductor Memory (ANSI)
Volume-Number: Volume 27, Number 55
From std-unix-request@uunet.UU.NET Wed Apr 1 21:59:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26737; Wed, 1 Apr 92 21:59:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28575; Wed, 1 Apr 92 21:59:21 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.2, Jan. 1992
Message-Id: <1992Apr2.025129.27673@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:15 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on POSIX.2: Shell and Utilities
David Rowley <david@mks.com> reports on the January 13-17
meeting in Irvine, CA:
Summary
The end is in sight. POSIX.2 (Shell and Utilities) Draft
11.2 closed its recirculation ballot last October 21. Draft
11.3 is due out any day now. A full draft (Draft 12) will
be recirculated to the IEEE working group before the final
standard is adopted. POSIX.2a (UPE) Draft 8 closed its
recirculation ballot on January 24. Both standards are
expected to be approved as full-use IEEE standards at the
September meeting of the IEEE Standards Board.
Work on POSIX.2b continues, including the contentious new
file format for PAX and extensions to the POSIX.2 utilities
to handle symbolic links.
The first cut at test assertions for POSIX.2 has been
wrapped up, and assertions for POSIX.2a begun.
Background
A brief POSIX.2 project description:
-- POSIX.2 is the base standard dealing with the basic
shell programming language and a set of utilities required
for the portability of shell scripts. It excludes most
features that might be considered interactive. POSIX.2
also standardizes command-line and function interfaces
related to certain POSIX.2 utilities (e.g., popen(),
regular expressions, etc.). This part of POSIX.2, which
was developed first, is sometimes known as ``Dot 2
Classic.''
-- POSIX.2a, the User Portability Extension or UPE, is a
supplement to the base standard. It standardizes commands,
such as vi, that might not appear in shell scripts, but
are important enough that users must learn them on any
real system. It is essentially an interactive standard,
and will eventually be an optional chapter to a future
draft of the base document. This approach allows the
adoption of the UPE to trail Dot 2 Classic without
delaying it.
Some utilities have both interactive and non-interactive
features. In such cases, the UPE defines extensions from
the base POSIX.2 utility. Features used both
interactively and in scripts tend to be defined in the
base standard.
-- POSIX.2b is a newly approved project which will cover
extensions and new requests from other groups, such as a
new file format for PAX and extensions for symbolic links.
Together, Dot 2 Classic and the UPE will make up the
International Standards Organization's ISO 9945-2--the
second volume of the proposed ISO three-volume POSIX
standard.
POSIX.2 Status
Hal Jespersen, Chair of POSIX.2, is about to send out Draft
11.3. This is likely the last ``changes-only'' draft of
POSIX.2.
The POSIX.2/D11.2 recirculation ballot closed October 21,
and resolution of ballot objections has completed.
Balloting of Draft 11.2 has been held open pending the
arrival of ISO comments. All changes for the next draft
(11.3) will be forwarded to ISO through the US TAG.
It is expected that a final draft 12 of POSIX.2 will be made
ready in time for the May WG15 meeting in New Zealand, and
should be approved as a Draft International Standard.
The technical content of the standard has more or less
stabilized. Most recent changes relate to clarifications in
wording.
POSIX.2a Status
POSIX.2a is also coming down the home stretch, as the
technical content has stabilized. Ballot resolution for
POSIX.2a (UPE) Draft 8 was completed. The ballot closed on
January 24. The next draft will likely be a quick
``changes-only'' recirculation, labelled draft 8.1. It
should appear any day now.
The ISO ballot ends in April. All comments will be rolled
into a Draft 9 which will be produced in time to be carried
to ISO in May for approval as a Draft International Standard
(DIS).
Hal Jespersen expects that both standards should be given
final full-use IEEE approval at the September meeting of the
IEEE Standards Board.
Internationalization Inadequacies
Randall Howard, President of MKS, put forward a proposal to
the POSIX.2b working group to define a system API to the
internationalization information embodied in a POSIX.2
locale. Routines to access collation elements, detect
membership within a character class and extensions to the
strftime() call were presented. The group felt that since
it was a system API, not a utility, it rightfully belongs in
POSIX.1. When the same presentation was given to POSIX.1,
they expressed the opinion that parts of the proposal were
better suited to the ANSI or ISO C Standard efforts.
Unfortunately, they don't necessarily want it since they
haven't (yet) adopted the POSIX.2 definition of a locale.
This all demonstrates that the POSIX process cannot
effectively deal with issues that cut across a number of
working groups and/or standards. Perhaps the Systems
Interface Coordination Committee (SICC) that has recently
been formed within POSIX can help address some of these
issues.
Comments on ISO 10646
The ISO working group that is responsible for the ISO 10646
character set standard (which now includes the Unicode
work,) has asked the POSIX.2 working group for their opinion
on their current proposal.
The working group expressed much concern over the use of
null octets within the valid character codes. Since
computer languages such as ``C'' make use of nulls as a
string termination marker, a lot of existing code would have
to be heavily modified in order to support the new standard.
The working group was against the proposal for this reason.
Apparently the ISO/ANSI C working group has expressed
similar concerns.
Symbolic Links
Dawn Burnett from USL submitted a proposal on extending the
POSIX.2 and POSIX.2a utilities to support symbolic links,
based on the System V implementation. The problems that
arise from symbolic linked directories were discussed at
length. There is nothing more irritating than changing to a
directory, printing the current working directory only to
find that you have been magically warped to a completely
different spot in the file system. A proposal to maintain
both physical (``Where am I'') and virtual (``How did I get
here'') paths was offered. The text will find its way into
the next draft of POSIX.2b for further discussion.
Test Methods
Real progress was made completing the remaining test
assertions for POSIX.2, and beginning the POSIX.2a work. A
style guide for writing consistent assertions has yet to
appear, but the group seems to have found its stride and is
working well.
Test assertions for the interactive utilities have yet to be
tackled, but it is expected that it will not be as difficult
as first anticipated. The assertions for ``vi'', ``talk'',
etc will describe (in precise English) what action must take
place upon the stated input. The process whereby the
results are verified will be left up to the test suite
implementor.
New PAX Archive Format
Work continues on the new PAX archive format. A consensus
is (slowly) starting to brew. The issue of supported
filename code sets is a thorny one, especially since POSIX
has not addressed any code set issues in a general way (such
as adopting the X/Open iconv utility and API).
The problems stem from wanting to use the format to address
both universal archive transportability as well as local
file system backup and restore. One concentrating on a
standard common ground, the other wanting the flexibility of
representing the full local filename character set. This is
the most contentious area of the format, and there will
likely be much wailing and gnashing of teeth before the dust
settles.
If you have any interest in this area, the group would be
pleased to hear from you.
Volume-Number: Volume 27, Number 56
From std-unix-request@uunet.UU.NET Wed Apr 1 21:59:24 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26745; Wed, 1 Apr 92 21:59:24 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28627; Wed, 1 Apr 92 21:59:30 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.6, Jan. 1992
Message-Id: <1992Apr2.025223.27860@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:16 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.6: Security Extensions
Charisse Castagnoli <charisse@sware.com> reports on the
January 13-17, 1992 meeting in Irvine, CA:
Summary of the POSIX meeting in Irvine
This was the first meeting of the POSIX.6 group since the
ballot closed on January 6, 1992. Of the 232 official
ballot members, 181 members responded. The response equals
78 %of the ballot pool. (A minimum of 75% response is
required by IEEE for a ballot to be considered valid.)
The 181 returned ballots were divided as follows:
Affirmative Negative Abstain
69 61 51
53% 47% <don't count>
In order for a ballot to pass, there must be a 75%
affirmative ballot. One would think this means 75% of the
responses must be affirmative, but this is not the case.
Only 75% of the non-abstaining votes need to be affirmative.
Taken to an extreme, this means that regardless of the
ballot pool size, if 3 people vote affirmative, 1 votes
negative and the rest abstain, the initiative passes. The
moral of the story is: abstain only as a last resort, there
may be deleterious side effects.
The POSIX.6 committee is now divided into 3 groups:
-- test assertions,
-- new projects,
-- ballot technical reviewers.
The test assertions group, led by David Rogers, is
developing the companion document of test assertions. This
is required to actually complete the ballot process.
The new projects group is working on new Project
Authorization Requests (PARs). Three PARs were presented:
-- one PAR for Identification and Authentication,
-- one for data interchange,
-- and one for terminal I/O.
In addition, PARs were prepared for the existing POSIX.6
functions. The current PAR for the existing functionality
will eventually be transformed into POSIX.6a (Security
Extensions to System Interfaces) and POSIX.6b (Security
Extensions to System Utilities and Shell). [ed. -_- PARs
are essentially administrative project control documents,
but are becoming administrative nightmares in the IEEE
standards development process.]
The ballot resolution group began reviewing the ballot
objections. A preliminary analysis indicated that one
common objection was lack of consistency within the ballot.
Requests for consistency in function naming, calling
parameters, data types and return codes were frequent.
After careful reflection, the ballot resolution group agreed
this was a reasonable request and began to work out a set of
guidelines to ensure consistency throughout the draft.
Highlights of the ballot resolution group discussions
include:
-- Should ``set'' and ``get'' be used for function names
instead of ``read'' and ``write?''
-- Should data types be contiguous in memory? (That is,
can a data object be copied with a bcopy().)
-- Should functions manage data storage and allocation or
should the programmer manage them?
After arduous negotiations, the group developed a set of
guidelines, that resolved many issues that have plagued the
drafts for years. The ballot resolution group will now join
the State Department to support peace negotiations in the
Middle-East.
The ballot resolution group tested the guidelines by
applying them to each of the primary functions in the draft.
These functional areas are privilege mechanism, mandatory
access control (including information labeling), and access
control lists. The auditing functions were granted an
exemption from this exercise, because they were being
reviewed in light of the new data type guidelines and
substantial interface modifications were expected.
Chris Hughes presented some options for new auditing
interfaces. The existing interfaces, in addition to being
inconsistent, lack good support for application level
auditing. Additional work is needed on the auditing
functions, and will be presented at the next POSIX meeting.
At the end of the meeting, we all agreed to try and complete
the interface changes necessary to bring each function in
line with the new guidelines. We also agreed to resolve as
many ballot objections as possible before the April meeting.
Volume-Number: Volume 27, Number 57
From std-unix-request@uunet.UU.NET Wed Apr 1 21:59:31 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26759; Wed, 1 Apr 92 21:59:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28652; Wed, 1 Apr 92 21:59:36 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.0, Jan. 1992
Message-Id: <1992Apr2.025310.28083@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:14 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.0: The Guide to Open Systems
Kevin Lewis <klewis@gucci.enet.dec.com> reports on the
January 13-17, 1992 meeting in Irvine, CA:
The POSIX.0 working group adjourned the October meeting
wondering what the mock ballot would yield. This ponderance
was focused not only on the size of the return, but also on
whether there were any hidden or significant issues lurking
in the darkness.
Twenty six mock ballot responses were received: 13 users, 9
producers, and 4 general interest participants. This
reflects a healthy balance. In total, there were
approximately 760 objections/comments. Some ballots covered
specific sections, while others addressed the entire guide.
It appears that the issue of ``public specifications'' that
has been lurking around in other venues has arisen here.
For those of you not familiar with this, I can not do it
justice here. Suffice it to say that it involves the use
within public procurements of specifications that are not
currently in the formal standards process but which have
widespread industry use and acceptance.
POSIX.0 feels that such specifications are acceptable under
specific conditions which include consensus, availability,
lack of encumbrances, and proper documentation. (There is
much, much more to this, so get a copy of the guide or call
someone in POSIX.0 if you are interested or concerned.)
The decision was made in January to move forward on the
formal ballot. POSIX.0 has notified the IEEE and a letter
forming the formal ballot group will go out in the March-
April time frame. The goal is to begin the formal ballot in
July 92. In parallel, POSIX.0 will be submitting the guide
to the international standards community in order to obtain
review and comment and to prepare the way for it as an ISO
Technical Report.
Volume-Number: Volume 27, Number 58
From std-unix-request@uunet.UU.NET Wed Apr 1 22:03:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26879; Wed, 1 Apr 92 22:03:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29480; Wed, 1 Apr 92 22:03:57 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.3, Jan. 1992
Message-Id: <1992Apr2.025344.28220@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:16 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
Report on POSIX.3: Test Methods and Conformance
Andrew Twigger <att@root.co.uk> reports on the January
13-17, 1992 meeting in Irvine, CA:
SCCT Matters
The Steering Committee on Conformance Testing (SCCT) met
three times during the week and discussed a broad range of
testing related issues. The major issues centred around
fitting the test methods into the document structure,
dealing with options in ``base'' standards, and test methods
for profiles.
The higher level of document structure seems to have been
resolved by introducing a parallel set of documents (and
therefore project requests, or PARs) to the base standards.
The test methods documents will be numbered by adding 1000
to the base standard number, i.e. POSIX.6 Security
Extensions (P1003.6) will have test methods in a document
numbered P2003.6. The IEEE would then resolve any
accompanying publication issues.
The more granular issue of how to write assertions which can
be easily merged along with the base standard was also
briefly discussed, but not yet concluded. The integration of
base standards (POSIX.1, POSIX.4, POSIX.6, etc.) is one of
the major problems facing TCOS at the moment, but the
solution seems as far away as ever. (The Technical Committee
on Operating Systems -- Standards Subcommittee, TCOS-SS, is
the IEEE Computer Society TC responsible for the POSIX
standards.)
From the test methods perspective, integrating assertions
for a pervasive interface like open() introduces a
considerable problem in defining which assertions relate to
which base standard options. While solutions can be produced
easily, these are generally inelegant.
The options issue, which was left over from the Parsippany
meeting was re-addressed with some further input from
POSIX.1. The problem may not be as serious as previously
thought and many of the issue can be resolved with some
minor changes to POSIX.3.1 (POSIX.1 Test Methods). The
remaining ones can be resolved by introducing an
announcement mechanism, which most test suites have to
provide, allowing the test suite to determine the
implementation's option setting.
The SCCT reviewed the meaning of profile conformance and the
use of conformance statements in profiles. They agreed that
profile conformance statements should refer back to those in
the base standards and should be validated by reference to
the test methods for the base standards, where available,
plus the specific test methods for the ``mortar'' defined in
the profile. (The Profiles Steering Committee is reaching
agreement on the rules for subsetting base standards, and
how additional behaviour may be thought of as the ``mortar''
binding the standards together.)
Software Testing Environment BOF
On Monday evening BSI (the British Standards Institution)
and Mindcraft called a Birds-of-a-Feather gathering to
explain Software Testing International and the Software
Testing Environment (STE). Software Testing International
would be a non-profit organisation set up to administer the
development of test suites for POSIX and other standards.
Most of the attendees seemed reticent in there approval of
the scheme, particularly when it became evident that
Mindcraft would be the sole test suite authoring
organisation with a seat on the Board. Comments from the
presenters that ``POSIX testing is just starting to become
serious'' were also not particularly well received. It
seemed clear that both structural and perceptual changes
would be necessary before the proposed scheme could make an
impact in the POSIX testing arena.
The actual STE introduces an additional API layer on top of
the current Test Environment Toolkit (TET), a freely
available testing harness created jointly by X/Open, Unix
International, and the Open Software Foundation. Initial
impressions were that the main purpose of this layer is to
allow Mindcraft's CTS based test suites to execute in the
TET environment. (NIST is currently supporting the TET as
their testing methodology of choice.)
Mindcraft promised to make the specifications available
shortly and to be providing an implementation at the end of
quarter two. The testing community will spend some time
reviewing the value of these extensions, but with
significant aspects like distributed testing omitted it may
not capture many peoples imagination.
POSIX.3
The POSIX.3 working group continued in there relentless task
of writing and reviewing assertions for the POSIX.2 (Shell
and Utilities) standard. The latest draft (POSIX.3.2/D7) has
been circulated for review and comment, though no comments
have yet been received. At the end of the Irvine meeting it
was expected that there would be no significant parts of
POSIX.2 that were unaddressed by test methods, except its
internationalisation aspects. The working group commenced
the specification of test methods for POSIX.2a (UPE) towards
the end of the meeting.
Other working groups were also developing test methods for
their standards with progress being made by (at least)
POSIX.6, POSIX.8, POSIX.12, 1224 and POSIX.17 as well as
some of the profile groups. In general these groups were
developing a reasonable understanding of the task facing
them, and in some cases good quality test methods have
already been produced.
The question of language independent test methods was
discussed in the POSIX.1 forum, though other groups (for
example 1224) have also made progress in this area. The
outcome of the POSIX.1 discussion was an estimate by a
prospective contractor to undertake 2,000 or more hours of
work to produce LIS test methods for POSIX.1. This looks
like an exceedingly high estimate and I would be very
surprised if TCOS followed it up!
Volume-Number: Volume 27, Number 59
From std-unix-request@uunet.UU.NET Wed Apr 1 22:03:58 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26894; Wed, 1 Apr 92 22:03:58 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29500; Wed, 1 Apr 92 22:04:04 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.14, Jan. 1992
Message-Id: <1992Apr2.025424.28370@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:17 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.14: Multiprocessor Profile
Rick Greer <rick@ivy.isc.com> reports on the January 13-17,
1992 meeting in Irvine, CA:
The multiprocessor working group plans to submit their draft
profile to a mock ballot after the April 1992 meeting. Much
of the January meeting was spent dealing with various
trivialities in the draft in anticipation of the mock
ballot. We did, however, encounter one major issue that
could prevent the draft profile from ever becoming a
standard. It seems that a draft profile cannot become a
``POSIX Standard Profile'' if it references documents which
are not themselves official standards endorsed by a
``recognized accrediting body''. The POSIX.14 draft
references both the POSIX.4 (Real-time) and POSIX.4a
(Threads) drafts, as well as some ongoing ANSI X3H5 work
defining parallel language facilities. It cannot become a
standard profile until all of these make their way through
the appropriate standardization mill.
The POSIX.14 profile is fairly simple, and likely to be
ready for balloting long before its antecedent documents.
This forces the POSIX.14 working group into one of a number
of possible holding actions:
1. Hold up balloting the POSIX.14 profile until all of the
referenced documents become standards. This will leave
the working group with very little to do, except perhaps
to work with the other groups to try and speed up
acceptance of their work. Since most of the POSIX.14
working group are refugees of the POSIX.4a threads wars,
there is very little enthusiasm within POSIX.14 for this
approach.
2. Go ahead and ballot the POSIX.14 profile, but don't
submit it to the IEEE Standards Board for approval until
the referenced documents become standards. This gives
the working group something to do over the next few
months (i.e, work on ballot resolutions). In the long
run it will only delay the inevitable: We are likely to
run out of ballot objections long before the other
documents become standards.
3. There are a number of ``missing interfaces'' that
POSIX.14 would like to see added to POSIX.1 and POSIX.2
but, being a profile group, is unable to specify. What
we can do is to recommend to other groups that they
incorporate these interfaces into subsequent versions of
their documents to better support multiprocessor
operation. The general feeling within POSIX.14 is that
if we do a thorough job of presenting well defined, well
rationalized, multi- processor interfaces, the other
working groups should pick them up with little argument
(ha!). While waiting for the draft documents referenced
by the POSIX.14 profile to become standards, the POSIX.14
working group could devote some effort to defining these
missing interfaces.
We pretty much decided to go with holding action number 3
(primarily because it's more fun than items 1 or 2), but
this course of action presents problems of its own. If we
wish to include the missing interfaces into the profile, we
will have to wait for them to become officially adopted into
POSIX.1 and POSIX.2. This would, of course, put us right
back where we started: Waiting for referenced documents to
become standards before the profile itself can be finished.
One way out of this dilemma is to include the missing
interfaces in an appendix to the profile itself. Once the
interfaces have become recognized standards, we can include
them in the normative text in a later revision of the
profile.
Volume-Number: Volume 27, Number 60
From std-unix-request@uunet.UU.NET Wed Apr 1 22:04:03 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26908; Wed, 1 Apr 92 22:04:03 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29555; Wed, 1 Apr 92 22:04:10 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX Dist. Security Group, Jan. 1992
Message-Id: <1992Apr2.025507.28513@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:19 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on the POSIX Study Group on Distributed Security
Laura Micks <uunet!aixsm!micks> reports on the January 15,
1992 meeting in Irvine, CA:
A study group has formed to investigate the feasibility of a
project request (PAR) for Distributed Security.
One of the major topics raised at the Distributed Services
Steering Committee (DSSC) was the problem of Security in a
Distributed environment. This issue is not addressed by the
Security working group (POSIX.6), nor any of the working
groups under the DSSC.
A meeting was scheduled for all interested parties to
discuss future directions in this area. Approximately 20
people attended and the application was made to be approved
as a Study Group. If approved, a Study Group can be funded
(from a logistics point of view) to meet for several
meetings without an official PAR in place. The group plans
to meet for an entire week next meeting cycle.
Most of the attendees were from the Security and Systems
Management groups. Several people attended for general
interest. It took the group quite some time to get rolling.
There seemed to be 2 camps: one that wanted to define a
conceptual model, identify services required, etc., and the
other that wanted to pin down the existing implementations,
choose one and tweek it where necessary.
A PAR was actually drafted in October 1991 by Data Logic on
behalf of Petr Janecek of X/Open. The PAR was not
officially submitted to the POSIX Sponsor Executive
Committee, probably due to potential lack of support and
sponsorship within the POSIX community. The draft of this
PAR was copied and distributed to the study group.
Known existing projects and organizations working similar
efforts were identified. The known models identified were
as follows:
-- Open Software Foundation's Distributed Computing
Environment (DCE)
-- NIS (Sun)
-- ECMA TC46 Technical Committee on Security Framework
-- ISO 7498-2 Security Addendum covering Architectural
Framework/Security Svcs
-- The Andrew File System (AFS)
-- Project Athena
-- GSSAPI - A generic security API from DEC
-- Project MAXSIX
-- DNSIX - (Mitre)
-- Netware
-- GASSP (Generally Accepted Security System Principles)
-- U.S. Government OSI Profile (GOSIP)
We decided to further the study by arranging as many
presentations as feasible from the list above for the April
meeting. The meeting agenda will be to hear the
architectural presentations on security models, and to
determine selection requirements for base documents. A
thorough evaluation will be made at the July meeting.
It is premature to assess the viability of this study group
becoming an actual POSIX committee. The initial meeting was
somewhat disorganized but in all fairness, there was little
or no advance notice of this group's meeting, hence the
attendees were unprepared. Given the sensitivity of the
subject and the obvious differences of opinions raised at
the January meeting, I don't expect that the exercise of
selecting a particular model to be used as a base document
will be trivial.
The next meeting will be held in conjunction with the next
IEEE POSIX working group meetings:
April 6-10, 1992,
The Doubletree Dallas at Lincoln Centre,
Dallas, TX.
Volume-Number: Volume 27, Number 61
From std-unix-request@uunet.UU.NET Wed Apr 1 22:04:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26919; Wed, 1 Apr 92 22:04:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29576; Wed, 1 Apr 92 22:04:16 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.17, Jan. 1992
Message-Id: <1992Apr2.025550.28681@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:17:18 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
Report on POSIX.17 - Directory Services API
Mark Hazzard <markh@rsvl.unisys.com> reports on the January
13-17, 1992 meeting in Irvine, California:
Summary
Once again, the POSIX.17 group made solid progress between
meetings, completing all major homework assignments. The
week in Irvine was a busy one. The Project Managment
Committee (PMC) audited POSIX.17 and gave the group a clean
bill of health. We also met with POSIX.12 furthering our
discussion on a simplified API to the directory. Our Mock
ballot input on the networking section of the Guide, POSIX.0
Draft 14, were reviewed with POSIX.0, with the promise that
they will be reflected in the next draft. We completed
processing input from our Mock Ballot of POSIX.17 Draft 2.0
and began drafting responses to our reviewers. We also
identified work items and continued planning for an official
IEEE ballot which begins April 7, 1992.
Introduction
The POSIX.17 group is generating a user to directory API
(e.g. an API to an X.500 Directory User Agent). We are
using the joint XAPIA -- X/Open Directory Services
specification (XDS) as a basis for work. XDS is an object
oriented interface and requires a companion document,
X/Open's Object Management specification (XOM) for object
management.
XOM is a stand-alone specification with general
applicability beyond the API to directory services. It will
also be used by IEEE P1224.1 (X.400 API), and possibly other
POSIX groups, and is being standardized by P1224. Draft 4
of P1224 has already entered IEEE ballot.
POSIX.17 is one of five "networking" groups that currently
make up POSIX Distributed Services and as such, POSIX.17
comes under the purview of the Distributed Services Steering
Committee (DSSC).
Status
The group chair was unable to attend the meeting in Irvine,
CA, so yours truely once again assumed the duties of chair.
There has been a low grumble about the ever increasing
overhead associated with TCOS/POSIX working groups, and now
I know why. A Project Management Committee audit Sunday
morning, 2 Sponsor Executive Committee (SEC) meetings, 2
Systems Interface Co-ordination Committee (SICC) meetings, 2
Distributed Systems Steering Committee (DSSC) meetings, 2
Distributed Systems (DS) Plenaries, a Logistics meeting, a
Distributed Security study and (I almost forgot) POSIX.17
working group meetings made for a noticeable lack of
``spare'' time.
Commitment within the group remains strong, with all other
core members attending, and completing their "homework"
assignments.
The TCOS Project Management Committee held the first audit
of POSIX.17 on Sunday morning. The PMC recommended
continued sponsorship of the work, splitting the work into
two projects, increasing the size of the working group for
ballot resolution and bringing our Issues Log current.
During the week, the group completed processing the comments
received from our Mock ballot. We began to draft written
responses which will be sent to all who took time to review
the draft and provide us with comments and/or objections.
Several of the comments/objections resulted in improvements
to the specification and will be incorporated into the next
draft (3.0). This will be the draft that goes directly to
IEEE ballot April 7th.
The Technical Editor completed the Language Independent
Specification (LIS) and a first cut at test assertions as
well. (X/Open followed through with their promise to fund
our technical editor to write the assertions for POSIX.17.
This made sense in that X/Open needs to have assertions for
XDS.) The test assertions were reviewed by a consultant from
POSIX.3 who had some problems with the way things were done.
A lively debate ensued, but in the end, we caved in, and
will incorporate the ``suggestions.'' It is estimated that
90% of our assertions will require change. Hopefully, this
can be automated.
Once again, we met with POSIX.12 (Protocol Independent
Interfaces) in joint session and discussed their
requirements on directory services. The POSIX.12 group wants
a simplified interface to directory services for the users
of their Detailed Network Interface (read sockets/XTI). We
also discussed what objects POSIX.12 will need to be stored
by the directory and how those objects will get documented.
Given our need to freeze our draft for ballot and the lack
of definition for both new objects and interface functions,
we explored possible avenues for proceeding with the work.
We met in small group to continue the discussion. POSIX.17
participants left the meeting with a greater understanding
of the issues, but no closer to a solution. We had a
debriefing session afterwards and decided to produce a white
paper documenting agreements, assumptions, issues, options
and proposed actions. This will be used to focus discussion
at the next small group meeting in April.
POSIX.17 and P1224 met again in joint session to
review/revise test assertions for P1224. Draft 4 of P1224
has already entered ballot and we agreed to assist them in
ballot resolution as time permits. Test assertions will be
balloted in a recirculation. Since P1224 is a normative
reference for POSIX.17, a stable version is essential for
our ballot.
We sent a representative to POSIX.0's Architecture Framework
BOF where the the results of their recent Mock Ballot were
discussed. POSIX.17 had submitted comments/objections to
the POSIX.0 Mock Ballot (Draft 14), focusing on the
``networking'' section. We were told that all our comments
and objections were accepted and will be included in the
next draft. The POSIX.0 model defined in the Mock Ballot
draft seemed to recognize the need for APIs aimed at systems
integrators as well as end users.
POSIX.17 shares a problem with P1224 and P1224.1. It seems
that the objects defined in the base documents (XDS, XOM,
X.400 API) reserved object ids (OIDs) in a vendor's (DEC)
registered ISO name space. This might be ok for vendor
consortia, but it won't cut it for a de jure standard.
Because this issue touches more than one group, the DSSC
discussed it and agreed to produce a recommendation on how
to proceed by next meeting.
In Closing ...
Again, there are quite a few homework assignments between
meetings. (I think there's a trend here). Given this is
our last quarter before ballot, we need to complete
formation of the ballot group, fix the test assertions,
finalize Draft 3, and respond formally to our Mock Ballot
reviewers. We've also been actioned by the DSSC and PMC to
split our current Project Authorization Request (PAR) into
two new PARs, one which addresses only the API to directory
services and the other which addresses the POSIX name space
issue.
The group will reconvene April 6-10, 1992 at the IEEE POSIX
meeting in the Dallas.
Volume-Number: Volume 27, Number 62
From std-unix-request@uunet.UU.NET Wed Apr 1 22:04:17 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26940; Wed, 1 Apr 92 22:04:17 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29598; Wed, 1 Apr 92 22:04:23 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Report on POSIX.17, Jan. 1992
Message-Id: <1992Apr2.025633.28833@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Wed, 1 Apr 1992 05:35:38 GMT
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: stephe@mks.com (Stephen Walli)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
Report on POSIX.17 - Directory Services API
Mark Hazzard <markh@rsvl.unisys.com> reports on the January
13-17, 1992 meeting in Irvine, California:
Summary
Once again, the POSIX.17 group made solid progress between
meetings, completing all major homework assignments. The
week in Irvine was a busy one. The Project Managment
Committee (PMC) audited POSIX.17 and gave the group a clean
bill of health. We also met with POSIX.12 furthering our
discussion on a simplified API to the directory. Our Mock
ballot input on the networking section of the Guide, POSIX.0
Draft 14, were reviewed with POSIX.0, with the promise that
they will be reflected in the next draft. We completed
processing input from our Mock Ballot of POSIX.17 Draft 2.0
and began drafting responses to our reviewers. We also
identified work items and continued planning for an official
IEEE ballot which begins April 7, 1992.
Introduction
The POSIX.17 group is generating a user to directory API
(e.g. an API to an X.500 Directory User Agent). We are
using the joint XAPIA -- X/Open Directory Services
specification (XDS) as a basis for work. XDS is an object
oriented interface and requires a companion document,
X/Open's Object Management specification (XOM) for object
management.
XOM is a stand-alone specification with general
applicability beyond the API to directory services. It will
also be used by IEEE P1224.1 (X.400 API), and possibly other
POSIX groups, and is being standardized by P1224. Draft 4
of P1224 has already entered IEEE ballot.
POSIX.17 is one of five "networking" groups that currently
make up POSIX Distributed Services and as such, POSIX.17
comes under the purview of the Distributed Services Steering
Committee (DSSC).
Status
The group chair was unable to attend the meeting in Irvine,
CA, so yours truely once again assumed the duties of chair.
There has been a low grumble about the ever increasing
overhead associated with TCOS/POSIX working groups, and now
I know why. A Project Management Committee audit Sunday
morning, 2 Sponsor Executive Committee (SEC) meetings, 2
Systems Interface Co-ordination Committee (SICC) meetings, 2
Distributed Systems Steering Committee (DSSC) meetings, 2
Distributed Systems (DS) Plenaries, a Logistics meeting, a
Distributed Security study and (I almost forgot) POSIX.17
working group meetings made for a noticeable lack of
``spare'' time.
Commitment within the group remains strong, with all other
core members attending, and completing their "homework"
assignments.
The TCOS Project Management Committee held the first audit
of POSIX.17 on Sunday morning. The PMC recommended
continued sponsorship of the work, splitting the work into
two projects, increasing the size of the working group for
ballot resolution and bringing our Issues Log current.
During the week, the group completed processing the comments
received from our Mock ballot. We began to draft written
responses which will be sent to all who took time to review
the draft and provide us with comments and/or objections.
Several of the comments/objections resulted in improvements
to the specification and will be incorporated into the next
draft (3.0). This will be the draft that goes directly to
IEEE ballot April 7th.
The Technical Editor completed the Language Independent
Specification (LIS) and a first cut at test assertions as
well. (X/Open followed through with their promise to fund
our technical editor to write the assertions for POSIX.17.
This made sense in that X/Open needs to have assertions for
XDS.) The test assertions were reviewed by a consultant from
POSIX.3 who had some problems with the way things were done.
A lively debate ensued, but in the end, we caved in, and
will incorporate the ``suggestions.'' It is estimated that
90% of our assertions will require change. Hopefully, this
can be automated.
Once again, we met with POSIX.12 (Protocol Independent
Interfaces) in joint session and discussed their
requirements on directory services. The POSIX.12 group wants
a simplified interface to directory services for the users
of their Detailed Network Interface (read sockets/XTI). We
also discussed what objects POSIX.12 will need to be stored
by the directory and how those objects will get documented.
Given our need to freeze our draft for ballot and the lack
of definition for both new objects and interface functions,
we explored possible avenues for proceeding with the work.
We met in small group to continue the discussion. POSIX.17
participants left the meeting with a greater understanding
of the issues, but no closer to a solution. We had a
debriefing session afterwards and decided to produce a white
paper documenting agreements, assumptions, issues, options
and proposed actions. This will be used to focus discussion
at the next small group meeting in April.
POSIX.17 and P1224 met again in joint session to
review/revise test assertions for P1224. Draft 4 of P1224
has already entered ballot and we agreed to assist them in
ballot resolution as time permits. Test assertions will be
balloted in a recirculation. Since P1224 is a normative
reference for POSIX.17, a stable version is essential for
our ballot.
We sent a representative to POSIX.0's Architecture Framework
BOF where the the results of their recent Mock Ballot were
discussed. POSIX.17 had submitted comments/objections to
the POSIX.0 Mock Ballot (Draft 14), focusing on the
``networking'' section. We were told that all our comments
and objections were accepted and will be included in the
next draft. The POSIX.0 model defined in the Mock Ballot
draft seemed to recognize the need for APIs aimed at systems
integrators as well as end users.
POSIX.17 shares a problem with P1224 and P1224.1. It seems
that the objects defined in the base documents (XDS, XOM,
X.400 API) reserved object ids (OIDs) in a vendor's (DEC)
registered ISO name space. This might be ok for vendor
consortia, but it won't cut it for a de jure standard.
Because this issue touches more than one group, the DSSC
discussed it and agreed to produce a recommendation on how
to proceed by next meeting.
In Closing ...
Again, there are quite a few homework assignments between
meetings. (I think there's a trend here). Given this is
our last quarter before ballot, we need to complete
formation of the ballot group, fix the test assertions,
finalize Draft 3, and respond formally to our Mock Ballot
reviewers. We've also been actioned by the DSSC and PMC to
split our current Project Authorization Request (PAR) into
two new PARs, one which addresses only the API to directory
services and the other which addresses the POSIX name space
issue.
The group will reconvene April 6-10, 1992 at the IEEE POSIX
meeting in the Dallas.
Volume-Number: Volume 27, Number 63
From std-unix-request@uunet.UU.NET Wed Apr 1 22:04:21 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26950; Wed, 1 Apr 92 22:04:21 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29616; Wed, 1 Apr 92 22:04:29 -0500
Newsgroups: comp.std.unix
From: Hans Mulder <hansm@cs.kun.nl>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Apr2.025716.28982@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: University of Nijmegen, The Netherlands
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net> <1992Mar31.204813.684@uunet.uu.net>
Date: Wed, 1 Apr 1992 11:09:11 GMT
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: hansm@cs.kun.nl (Hans Mulder)
In <1992Mar31.204813.684@uunet.uu.net> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1992Mar31.024454.23050@uunet.uu.net> djm@eng.umd.edu (David J. MacKenzie) writes:
>>The only explicit mention of `#' for the shell in p1003.2a is in the
>>description of the Vi editing mode. It's a command to comment-out the
>>current line (excerpted below). ...
>That's disgusting!
>If 1003.2 is going to break zillions of existing carefuly-written shell
>scripts, then it ought not to be adopted.
You're confusing 1003.2 with 1003.2a. 1003.2 mentions that `#' is the
comment character in scripts and people want 1003.2a to say that it
also works interactively. That goes without saying for people who are
used to sane shells, but many netters are used to the C shell, which
gets this sort of detail wrong. Apparently, at least one vendor has
seen fit to duplicate this bug in an otherwise Bourne compatible shell.
--
Hans Mulder hansm@cs.kun.nl
Volume-Number: Volume 27, Number 64
From std-unix-request@uunet.UU.NET Wed Apr 1 22:04:26 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26959; Wed, 1 Apr 92 22:04:26 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29633; Wed, 1 Apr 92 22:04:34 -0500
Newsgroups: comp.std.unix
From: Tom Glinos <tg@utstat.toronto.edu>
Subject: Is POSIX a waste?
Message-Id: <1992Apr2.025846.29245@uunet.uu.net>
X-Submissions: std-unix@uunet.uu.net
Organization: University of Toronto, Dept. of Statistics
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net> <1992Mar31.212031.4967@uunet.uu.net>
Date: Wed, 1 Apr 1992 16:09:53 GMT
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: tg@utstat.toronto.edu (Tom Glinos)
At the risk of being flamed back into the stone age I'll offer
the opinion that the whole POSIX exercise has been a waste, for
the following reasons.
[1] It's never been clear to me what the original POSIX proposals were
supposed to define and accomplish. (What is the deliverable?)
[2] This led to the ever widening number of groups. (More deliverables.)
[3] Some groups then started to argue and propose interfaces that in
some cases had never been widely implemented or thoroughly studied.
[4] Some groups have let company and market pressures direct what should
be an exercise in common sense and good engineering.
It's been a bit more than a year since I looked at any POSIX document.
If memory serves me correctly it's been about 5 years since the first
document was tabled. Has nothing been voted on? When will it all end?
--
=================
"Life is so much more meaningful if you take the time to hunt down and strangle
twits who post blather to inappropriate newsgroups." Henry Spencer
Volume-Number: Volume 27, Number 65
From std-unix-request@uunet.UU.NET Wed Apr 1 22:04:42 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA26999; Wed, 1 Apr 92 22:04:42 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA29645; Wed, 1 Apr 92 22:04:42 -0500
Newsgroups: comp.std.unix
From: "Robert L. Knighten" <knighten@intel.com>
Subject: Re: P1003.4[a] Common Reference Ballots (CRBs)
Message-Id: <1992Apr2.025929.29370@uunet.uu.net>
Reply-To: Bob Knighten <knighten@ssd.intel.com>
X-Submissions: std-unix@uunet.uu.net
Organization: Intel Supercomputer System Division, Beaverton, OR
References: <1992Mar27.212634.11619@uunet.uu.net>
Date: Wed, 1 Apr 1992 20:53:48 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: knighten@intel.com (Robert L. Knighten)
Draft 12 of the P1003.4 (Realtime Extension) draft standard is in its fourth
ballot (and third recirculation.) This latest ballot is due at the IEEE
Standards Office on April 10.
Last work the following group met and drafted a Common Reference Ballot which
we hope will be considered by other members of the ballot group before they
submit their own ballots. Our CRB is included at the end of this message.
The CRB will be submitted as the first 40 items in the ballot of
Robert L. Knighten of Intel Supercomputer Systems Division.
Nawaf Bitar Kubota-Pacific
David Black Open Software Foundation
Bob Conti Digital Equipment Corporation
Bill Cox Unix Systems Laboratories
Michael Jones Carneige-Mellon University
Steve Kleiman SunSoft
Bob Knighten Intel Supercomputer Systems Division
Jim Pitcairn-Hill Open Software Foundation
Dave Plauger Hewlett-Packard
Paul Rabin Open Software Foundation
This CRB is also available in various forms (ASCII, postscript, troff) by
anonymous ftp from export.ssd.intel.com in the directory /pub/tmp/CRB.
This same group has also done a common reference ballot for the P1003.4a
(Pthreads) draft and that will be available on April 13.
==============================================================================
--------------------------------------------------------------------------
@ all o 1
1: Section all page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1 functions
and their close relatives (e.g. fdatasynch()) should maintain their overall
structure, as should those tied to existing practice (e.g. mmap, memlock, et
al.). The use of errno as a global error indicator in multithreaded
environments introduces new difficulties.
ACTION:
New functions (e.g. aio_read, sem_post) should not set a global errno, but
instead return an error indication as the function return value. We do not
provide synopses for all such functions, but will on request from the
technical reviewers.
Change all new functions such as the aio functions and sem_ functions to
return an error indication on failure.
--------------------------------------------------------------------------
@ all o 2
2: Section all page all line(s)
OBJECTION:
We join in UO193.D11. The performance metrics are not consistent, and are not
appropriate to this standard. Improving something that does not belong does
not solve the problem. Deleting them will. The problem is not quality but
timeliness and applicability.
ACTION:
Delete all performance metrics from D12 and forward the text to a
benchmarking standards group.
--------------------------------------------------------------------------
@ Introduction c 3
3: Section Introduction page viii line(s) 17-18
COMMENT:
This makes the same sweeping generalization as in lines 16-17 page 2, and
should also be amended and clarified.
--------------------------------------------------------------------------
@ 1.1 o 4
4: Section 1.1 page 1 line(s) 5
OBJECTION:
We join with unresolved objection UO.3.D11. Performance metrics are not the
appropriate province of a source interface standard. There are groups that
define benchmarks; the information requested in the performance metrics
sections (sections 3.9.10, 3.10.5, 6.6.3, 6.7.9, 17.3, 19.2, 20.3, 20.4.6,
21.4, 21.5.5, 22.3, 23.3, 23.4.6, 24.4, and 24.5.8) should be defined by
those groups, and not TCOS-sponsored POSIX working groups.
ACTION:
Delete line 5. In addition, delete all performance metrics as out of scope.
--------------------------------------------------------------------------
@ 1.1 o 5
5: Section 1.1 page 2 line(s) 12-44
OBJECTION:
We have objected previously to the extremely broad definition of "realtime,"
and we continue to object vigorously. As part of this objection we point out
that using names such as "{_POSIX_MAPPED_FILES}" and "{_POSIX_SEMAPHORES}"
contributes to the vague broad definition of "realtime" being used.
It is encouraging that application to multiprocessors and networking are
specifically excluded from scope. However, the extremely broad nature of
lines 22-23 renders the limiting to a "...set required to make this standard
minimally useful to realtime applications on single processor systems" (lines
12-13) a too-subtle attempt at humor.
The reviewer's response to unresolved objections (e.g. to W. T. Cox D11
objection 7, marked "nonresponsive") is itself not a response but an excuse.
In part, the reviewer said "...the scope is determined by the approved PAR
and further refined in the informative text of the draft. The items
[asynchronous I/O and realtime files, among others] ... are well within
scope."
We would appreciate the specification of any interface that is not within the
scope as written in D12 and previous drafts. The only justification that
appears to serve to delete functionality that is not considered "realtime" is
an outcry from the balloting group. POSIX.4 appears to take the mechanistic
(and self- referential) approach that "realtime is anything that's in
POSIX.4." This absence of anything outside your scope makes it difficult to
convince the technical reviewers that any particular 'nice interface' is
inappropriate -- you may only be able to convince them that the time is not
opportune to slip it past a balloting group.
Moreover, objections to the broad nature of the scope have been called
"nonresponsive," and not circulated with other rejected comments to the
balloting group. What is more responsive to a call to validate a standard
with broad support than questions about the purpose and scope?
ACTION:
The scope must be narrowed. One modification that would satisfy this
objection is to delete line 5 and replace lines 18-26:
The key elements defining scope are
(a) defining a sufficient set of functionality to cover a significant part of
the realtime application domain, and
(b) ensuring that the simultaneous support of the realtime extensions do not
impose undue burdens upon implementations that attempt to simultaneously
support both realtime extensions, POSIX.1 base functionality, and other
extensions currently being developed to POSIX.1.
Specifically within the scope is to define interfaces which do not preclude
high performance implementations on traditional uniprocessor realtime
systems, but also to extend while focusing on traditional realtime systems
and needs such as timers, shared memory, scheduling, and interprocess
communication.
The establishment of performance metrics are specifically out of scope; text
for proposed metrics are included in the rationale for each section, and will
be forwarded to other bodies for standardization.
The establishment of benchmarks and performance enhancements for file systems
is also specifically out of scope.
The signal mechanisms of POSIX.1 and existing implementations are already
extremely complex. Adding an additional layer of complexity would not ensure
that high performance implementations and applications can be built using
such signal extensions. Accordingly, extensions to the POSIX.1 signals
mechanism are specifically out of scope.
Wherever possible, the requirements of other application enrironments are
included in the interface definition.
It is beyond the scope of these interfaces to support networking or
multiprocessor functionality. (Rationale note: With this limitation on the
uniprocessor scheduling interfaces, all of the remaining functionality is
appropriate for closely-coupled multiprocessor systems.)
--------------------------------------------------------------------------
@ 2.2 o 6
6: Section 2.2 page 6 line(s) 24-25
OBJECTION:
Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
discussed in the rationale to Chapter 24, so the definition does not belong
in normative text.
ACTION:
Delete Lines 24-25.
--------------------------------------------------------------------------
@ 2.2 o 7
7: Section 2.2 page 10 line(s) 178-179
OBJECTION:
Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
(according to the index) discussed in the rationale to Chapter 24, so the
definition does not belong here.
ACTION:
Delete Lines 178-179.
--------------------------------------------------------------------------
@ 3.3 o 8
8: Section 3.3 page 23-24 line(s) 154-166
OBJECTION:
SI_TIMER and SI_ASYNCIO and SI_MESGQ require either (1) a kernelized
implementation or (2) the ability for a user-level implementation to "fake" a
signal source. The existence of these SI_ values is in conflict with the
rationale and text for asynch I/O and other functions which say that
threads-based implementations should not be precluded.
Sigqueue would have to similarly be a kernel implementation or have a back
door.
Similarly, the timer mechanism would have to have a back door way to fake the
SI_TIMER codes. This has been a system-supplied value that cannot be spoofed
in the existing practice; a shift to signal-sender- settable values would be
a breach of existing practice and expectations.
ACTION:
Delete this entire section; in the alternative, delete lines 157-162 and
(editorially) all references to the deleted text.
--------------------------------------------------------------------------
@ 3.3 o 9
9: Section 3.3 page 23 line(s) 159-160
OBJECTION:
Forcing the signal code to return SI_ASYNCIO substantially complicates
implementations that implement asynchronous I/O by using threads. It forces
the implementation to modify the signal catching mechanism to cause a special
code to generated. Moreover, this requirement prevents an implementation
using threads.
ACTION:
Delete lines 157-158
--------------------------------------------------------------------------
@ 3.3 o 10
10: Section 3.3 page 21-38 line(s) all
OBJECTION:
The use of signals for notification of events of interest is a
low-performance technique. We have made objections whose action, if accepted,
will eliminate the need for signal notification of events of interest
including timer firing, asynchronous I/O completion, and IPC message
notification.
The general idea is to pass or use a pointer to a function taking the
appropriate type as a parameter. There are two additional modifications
needed to support this improvement.
ACTION:
On p20 line 41, delete the word "signal." (Notifications in exec'd process
are impossible.)
On p21 l64 delete the word "signal."
Delete section 3.3.
--------------------------------------------------------------------------
@ 5.4.5 o 11
11: Section 5.4.5 page 82 line(s) 416-482
OBJECTION:
We join in UO38.D11 and UO47.D11. The shm_open() and shm_unlink() interfaces
serve no useful function and introduce needless confusion in code that will
use different functions for effectively the same purpose.
ACTION:
Delete shm_open() and shm_unlink().
--------------------------------------------------------------------------
@ 6 o 12
12: Section 6 page all line(s) all
OBJECTION:
These operations are trivially and more efficiently performed by using
threads.
ACTION:
Delete this chapter.
--------------------------------------------------------------------------
@ 6.7 o 13
13: Section 6.7 page 59-77 line(s) 458-1118
OBJECTION:
This section on asynchronous I/O has improved from previous drafts, but still
has a number of major problems:
Notification is far too complex. The alternative of using OPTIONAL realtime
signals seems peculiar, and a burden on the programmer.
The focus needs to be on creating interfaces that are implementable using the
synchronous I/O of threads.
The reviewer's response to UO148.D11 is interesting, as he says that the
current chapter is not existing practice. This reinforces other unresolved
objections that state that the contents of this Section do not reflect
existing practice.
ACTION:
Delete this Section.
--------------------------------------------------------------------------
@ 6.7 o 14
14: Section 6.7 page 59-77 line(s) 458-1118
OBJECTION:
The response to UO148.D11 is not clear; the full text of the objection was
not presented. Since this text provided an alternative to the Section, UO148
was responsive, but the balloting group can neither evaluate text it has not
seen nor appreciate references to text not supplied in the unresolved
objections list.
ACTION:
Include the text of unresolved objections per IEEE Standards Board procedures
and IEEE rules. Deliver the full text of UO148.D11 to the balloting group so
that references to that text in other unresolved objections make sense.
--------------------------------------------------------------------------
@ 6.7 o 15
15: Section 6.7 page 59-77 line(s) 458-1118
OBJECTION:
In the event that our previous objection or others calling for deletion of
this section are not accepted, we make the following objection to the
notification mechanism. The action also addresses the problems stated in
unresolved objections numbers 149, 150, 152, 154, 156, and 157.
The use of optional realtime signals is a burden, as a portable application
cannot know how much data can be passed, and a specific signal handling
routine must be scheduled after an expensive signal is sent.
This is not consistent with "not precluding high-performance implementations"
as stated on page 2 lines 22-23. Signals by their very nature are low in
performance, and so-called "realtime signals" do not correct the situation.
In addition, the atomic update problem cited in, for example, UO.154.D11 and
the reviewer's response, is addressed.
ACTION:
A simpler solution, provided in unresolved objection UO148.D11 but
accidentally deleted by the Unresolved Objections Editor, is to provide a
function to be called when the I/O operation is completed. This is an
element of struct aiocb, and aio_errno and aio_result can be added to struct
aiocb and the functions aio_error and aio_return can be deleted.
The new element, aio_notifunction (the name isn't very important, but the
concept is), is a pointer to a function that takes a pointer to struct aiocb
as its argument. When the asynchronous I/O operation completes, the function
referred to by aio_notifunction is called with a pointer to the completed
aiocb as its parameter. The notification function must be coded as if it has
no context: the effect of specifying a function that does process control,
longjmp, or thread control calls that assume a particular environment is
undefined.
The rationale should state that the action of calling the notification
function is the final one performed by the implementation after updating the
aio_errno and aio_result fields. The notification function may send a signal,
in which case the result will be as in D12. The notification function can (in
effect) directly run the signal handler that would deal with the asynch I/O
completion.
To make this approach even more flexible, an atomic_t element can be added to
struct aiocb to atomically mark the aiocb as completed.
--------------------------------------------------------------------------
@ 9.2.1.2 o 16
16: Section 9.2.1.2 page 176 line(s) 93-97
OBJECTION:
The consensus in P1003.4 is clearly to not use the file system as the name
space for their handles. Unfortunately the current "maybe it's in the file
system and maybe it's not" semantics only confuses the issue further.
ACTION:
Change these lines to say that if {_POSIX_OBJECTS_ARE_FILES} is defined, then
the names are true path names; otherwise the indicated things are unspecified.
--------------------------------------------------------------------------
@ 9.2 o 17
17: Section 9.2 page 179 line(s) 211-214
OBJECTION:
We join in UO142.D11. The variety of message passing systems make this an
unreasonable requirement on implementations.
ACTION:
Leave the last close behavior unspecified.
--------------------------------------------------------------------------
@ 17 o 18
18: Section 17 page all line(s) all
OBJECTION:
Several problems here.
The apparent reason for this chapter was to replace the System V semaphores.
The only reason that POSIX.4a semaphores aren't a complete replacement is
that some machines don't have shared memory. The embedded case can be
supported using D11 semaphores with some minor changes.
Naming semaphores, while odious, is implementable on top of higher
performance POSIX.4a semaphores. Simplification via shared memory semaphores
is a real benefit to users and implementors.
The goal of being implementable on all systems is met by implementations on
systems without memory management hardware using pointers in the semaphore
objects to refer to common synchronization objects, i.e., using an additional
level of indirection.
ACTION:
Define shared memory semaphores as defined on the following manual pages.
1. sem_init() Initialize a Semaphore
NAME sem_init
DESCRIPTION sem_init() initializes the named semaphore to a known state.
SYNOPSIS
#include <synch.h>
int sem_init(sem_t *sema, int sem_count, int type, void *arg);
PROCESSING sem_init(), initializes the semaphore sema of type type to a known
state.
The parameter sem_count must be greater than or equal to zero, defines the
initial count of resources protected by the semaphore. Once initialized, the
semaphore can be used any number of times without being re-initialized. A
semaphore should not be re-initialized while threads are waiting at the
semaphore.
If type is USYNC_THREAD the semaphore is initialized for threads within a
single process. Specification of USYNC_PROCESS for the type will initialize
the semaphore for threads across processes.
The arg is reserved for future use.
All operations on semaphores initialized with sem_init() are non-recursive;
the error check is done under the DEBUG option to detect their recursive use.
Statistics and performance data will be collected under the DEBUG option.
OUTPUT On successful completion, sema is initialized and the operation returns
zero. Otherwise, the contents of sema are unchanged and an appropriate error
indication value is returned. ERROR/DIAGNOSTICS If any of the following
conditions is detected, sem_init() fails and returns the corresponding value:
EINVAL Invalid argument specified.
EBUSY An attempt is made to initialize a semaphore while threads are waiting
at the semaphore.
SEE ALSO sem_wait , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
17.2.1.
2. sem_wait() Wait on a Semaphore
NAME sem_wait
DESCRIPTION sem_wait() is used to claim resources under the semaphore's
control.
SYNOPSIS
#include <synch.h>
int sem_wait(sem_t *sema);
PROCESSING sem_wait() acquires sema by decrementing the semaphore value. If
the resulting value is greater than or equal to zero, it returns success
having acquired sema. If the semaphore count is zero upon entry, sem_wait()
suspends execution of the calling thread and places it on a queue associated
with sema where it remains until sema becomes available to the caller (i.e.,
the count is greater than zero), at which point sem_wait() decrements the
count and returns success having acquired sema. (A negative value for the
count is illegal.)
sema must previously have been initialized.
In general, this operation is used to block wait for an event, or when a
critical section is long.
This operation keeps track of statistics and performance data under the DEBUG
option.
If a thread waiting on a semaphore is interrupted by a signal, the signal
handler will run, but sem_wait is always restarted so the semaphore is held on
return. OUTPUT The operation returns zero if the semaphore is successfully
acquired. ERROR/DIAGNOSTICS If any of the following conditions is detected,
sem_wait() fails and returns the corresponding value:
EINVAL Invalid argument specified.
SEE ALSO sem_init , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
17.2.4.
COMMENTS While a sem_wait can be interrupted by a signal or a fork, an
EINTR is never returned to the user: the wait must be restarted.
3. sem_trywait() Conditional Locking
NAME sem_trywait
DESCRIPTION sem_trywait() is used to claim resources under the semaphore's
control.
SYNOPSIS
#include <synch.h>
int sem_trywait(sem_t *sema);
PROCESSING sem_trywait() makes a single attempt to acquire the lock sema, but
does not block in the case of a failure. The sema must have been previously
initialized.
This operation keeps track of statistics and performance data under the DEBUG
option. OUTPUT The operation returns zero if the lock is successfully
acquired and an appropriate error indication value if the lock could not be
acquired. ERROR/DIAGNOSTICS If any of the following conditions is detected,
sem_trywait() fails and returns the corresponding value:
EINVAL Invalid argument specified.
EBUSY The semaphore is in the locked state.
SEE ALSO sem_init , sem_wait , sem_post , sem_destroy , POSIX.4/D12 Section
17.2.4.
4. sem_post() Unlock a Semaphore
NAME sem_post
DESCRIPTION sem_post() releases a lock by incrementing the count value of the
semaphore.
SYNOPSIS
#include <synch.h>
int sem_post(sem_t *sema);
PROCESSING sem_post() releases a resource under the semaphore control sema
(increments the semaphore value) acquired by a previous call to either
sem_wait(), or sem_trywait(), and if the new count value is less than or equal
to zero, the next thread waiting at the semaphore will be made runnable.
sem_post() will fail when releasing a resource would over-increment the
semaphore count value and the DEBUG mode is enabled.
This operation keeps track of statistics and performance data under the DEBUG
option.
If more than one thread is waiting, release from the blocked group is
scheduling policy specific for bound threads, and may be dependent on
scheduling parameters for multiplexed threads. OUTPUT On successful
completion, the operation returns zero. ERROR/DIAGNOSTICS If any of the
following conditions is detected, sem_post() fails and returns the
corresponding value:
EINVAL Invalid argument specified.
ENOLCK The semaphore is not in the locked state.
SEE ALSO sem_init , sem_wait , sem_trywait , sem_destroy , POSIX.4/D12 Section
17.2.5.
5. sem_destroy() Destroy a Semaphore
NAME sem_destroy
DESCRIPTION sem_destroy() attempts to destroy a semaphore.
SYNOPSIS
#include <synch.h>
int sem_destroy(sem_t *sema);
PROCESSING sem_destroy() attempts to destroy a semaphore, i.e., free up all
dynamically allocated resources associated with the given semaphore, and/or
invalidates statically allocated object (e.g., it will free up the statistics
buffer dynamically allocated under the DEBUG option).
The parameter sema identifies the semaphore to be destroyed. OUTPUT On
successful completion, the operation succeeds and returns zero.
ERROR/DIAGNOSTICS If any of the following conditions is detected,
sem_destroy() fails and returns the corresponding value:
EINVAL Invalid argument specified.
EBUSY An attempt to destroy semaphore was made while the semaphore was
locked by another thread.
SEE ALSO sem_init , sem_wait , sem_trywait , sem_post , POSIX.4/D12 Section
17.2.2.
--------------------------------------------------------------------------
@ 17 o 19
19: Section 17 page all line(s) all
OBJECTION:
sem_lock, sem_trylock, and sem_unlock are bad names for counting semaphores.
Existing practice would indicate use of either P & V or post and wait. P and
V are easily confused, therefore...
ACTION:
Use the names sem_post, sem_wait, and sem_trywait.
--------------------------------------------------------------------------
@ 17.2 o 20
20: Section 17.2 page 89-93 line(s) 12-147
OBJECTION:
The "harmonization" between .4 semaphores and .4a synchronization primitives
is inadequate. It forces the application to explicitly name each semaphore
that span process boundaries. It does not provide adequate protection for
using inter-process semaphores in that protection cannot be set. In addition
it conflicts with the obvious way one would use POSIX.4a style semaphores.
ACTION:
Delete sem_open(), sem_destroy(), and sem_unlink(). Replace them with
pthread_semattr_init(pthread_semattr_t *attr);
pthread_semattr_destroy(pthread_semattr_t *attr);
pthread_semattr_getpshared(pthread_semattr_t *attr, int *pshared);
pthread_semattr_setpshared(pthread_semattr_t *attr, int pshared);
pthread_sem_init(pthread_sem_t *sem, pthread_semattr_t *attr);
pthread_sem_destroy(pthread_sem_t *sem);
When semaphores are to be shared across process boundaries then they are
placed in a shared memory object or mapped file. This provides a global name
for independent processes to use, and it provided a well-defined protection
mechanism.
--------------------------------------------------------------------------
@ 20 o 21
21: Section 20 page 117 line(s) 2-14
OBJECTION:
Normative text has been moved to the rationale regarding the following
behaviors: - writes to memory shared between processes appear in the other
mapping processes (lines 465- 469). - behavior on protected or unmapped
references (lines 486-496).
ACTION:
Add the lines specified above after line 14.
--------------------------------------------------------------------------
@ 20 o 22
22: Section 20 page 117 line(s) 2-14
OBJECTION:
The text does not specify that the address of the reference that caused the
SIGBUS or SIGSEGV should be delivered to the signal handler that specifies
SA_SIGINFO.
ACTION:
Add after line 14 something like:
When a SIGSEGV or SIGBUS is delivered and the SA_SIGINFO flag is set, the
sival_ptr member of sigev_value shall be set to the address of the reference
that caused the signal to be generated. The address may rounded down to the
nearest {_SC_PAGESIZE} boundary.
--------------------------------------------------------------------------
@ 21 o 23
23: Section 21 page all line(s) all
OBJECTION:
The scheduling interfaces have become more cumbersome as the drafts have
progressed. It is time for a simplification.
ACTION:
Replace this chapter's interfaces with a parallel to the Pthreads POSIX.4a
CRB proposals. The interfaces that should be supported are
yield()
set_sched_attr() for startup
inheritance from creator
set_self_scheduler (struct...)
get_self_scheduler ( struct *... )
set_scheduler (pid_t, struct...)
get_scheduler (pid_t, struct *... )
--------------------------------------------------------------------------
@ 21 o 24
24: Section 21 page all line(s) all
OBJECTION:
We join in Unresolved Objections 81, 89, 95, and 97.
As stated in UO89.D11, you can't have your cake and eat it too -- SCHED_OTHER
is not an escape from realtime scheduling. The reviewer's response
contradicts the statement in D12 that SCHED_OTHER may be the same as either
SCHED_FIFO or SCHED_RR. You can't have it both ways...
UO97.D11 brings up the identification of schedulers problem. A simple
implementation could define SCHED_OTHER to be zero, SCHED_FIFO to be zero,
and SCHED_RR to be one. How do you tell what the result of a getscheduler()
call is? Remember, the value of SCHED_OTHER is a compile-time constant.
ACTION:
Change all occurrences of SCHED_OTHER to SCHED_DEFAULT. In the alternative,
define a new interface sched_default() which returns an indicator of the
default scheduler for the implementation. This should probably be a string,
but a name would be even better. This eliminates the need for a SCHED_OTHER
constant.
--------------------------------------------------------------------------
@ 21 o 25
25: Section 21 page all line(s) all
OBJECTION:
The use of SCHED_OTHER is confusing. SCHED_OTHER is simply a placeholder for
"some scheduling algorithm that may be different or not different from
SCHED_FIFO and SCHED_RR". This suggests both that SCHED_OTHER is a name for
some specific scheduling algorithm AND that SCHED_OTHER is a name for some
selectable scheduling algorithm that may be different from SCHED_FIFO and
SCHED_RR.
Unfortunately, SCHED_OTHER can't be both. The apparent meaning is of some
system-defined policy that is neither FIFO nor RR, but over-generalization in
the text of this section makes that incorrect as well. A more appropriate
name is "SCHED_DEFAULT." The reviewer's comments on UO81.D11 is not
persuasive. Perhaps another name would be acceptable to the balloting group?
We believe that SCHED_DEFAULT is the best that has been proposed so far.
ACTION:
Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter.
--------------------------------------------------------------------------
@ 22 o 26
26: Section 22 page 168- line(s) 36ff
OBJECTION:
Timer firing notification should be should be be a function as in our
proposal for asynch I/O. This style of notification allows flexible
prioritization of timer completion events without the overhead of sending a
signal.
ACTION:
A simpler solution, similar to that provided in unresolved objection
UO148.D11 but accidentally deleted by the Unresolved Objections Editor, is to
provide a function to be called when the timer fires.
Replace the evp argument with a pointer to a function with a single parameter
of type clock_t. Change p171, lines 146-148 and 153-162 to match. Correct the
prototype.
--------------------------------------------------------------------------
@ 22.2 c 27
27: Section 22.2 page 171 line(s) 137
EDITORIAL COMMENT:
The type of the *evp parameter is missing. If our other objections are not
accepted, this should read ... struct sigevent *evp.
--------------------------------------------------------------------------
@ 23 o 28
28: Section 23 page all line(s) all
OBJECTION:
IPC message notification should be a function as in our proposal for asynch
I/O. This style of notification allows flexible prioritization of IPC
completion events without the overhead of sending a signal.
ACTION:
Change the notification parameter on p191 lines 16-17 to type pointer to
function with parameter mqd_t. Change lines 347-354 to match the new meaning
for notification.
--------------------------------------------------------------------------
@ 23 o 29
29: Section 23 page all line(s) all
OBJECTION:
The message-received notification is within a process, and (rather than the
optional realtime signals) should be as we have proposed for asynch I/O.
--------------------------------------------------------------------------
@ 23 o 30
30: Section 23 page 191-210 line(s) 1-656
OBJECTION:
In reference to D11 Unresolved Objections 133, 142:
The interfaces in this chapter are not based on current practice. In
particular, none use the file system as the name space for their handles, for
good reason. It confuses the semantics of both the message queues and the
file system and is not extensible over the network. The current "maybe it's
in the file system and maybe it's not" semantics only confuses the issue
further.
I believe that it is possible to meet all the requirements expressed by the
rationale by minimal extensions to the BSD sockets interface or the X/Open
XTI interface. Indeed, the working group has recognized this possibility and
asked .12 to do so. It should be possible to meet the valid real time
requirements through extensions to existing, more general interfaces, rather
than through introduction of a new (although much improved from previous
drafts!) set of interfaces.
At the very least, any new .4 IPC interface should be implementable entirely
on top of sockets, or in terms of threads and shared memory.
In summary, We believe that no convincing rationale has been presented for
the addition of completely new IPC interfaces.
ACTION:
The proposed interfaces should be replaced with one based on an existing
interface, ideally one that has potential to be used in a distributed
environment, including those in which the file systems are not shared (i.e.
are not syntactically linked with the file system). Our preferred candidate
would be to utilize the BSD sockets and X/Open XTI interfaces as being
standardized by .12, with the addition of a real time protocol.
Alternately, this objection can be satisfied by deleting the IPC chapter.
--------------------------------------------------------------------------
@ 23.1.1 o 31
31: Section 23.1.1 page 192 line(s) 26-28,46-53
OBJECTION:
In reference to D11 Unresolved Objections 134, 136:
The mq_sendwait, mq_rcvwait, and mq_curmsgs fields cannot be counted on to
remain fixed between a reading of the fields and any subsequent action within
a program. Therefore, it's not clear what use any program could reliably make
of this data. The application can only tune itself if it has control over all
consumers of the queue and diagnosis is not in the province of POSIX.
Also, counting the number of waiting processes precludes implementations in
shared memory using pthreads-like synchronization primitives. First, some
synchronization primitives don't keep track of the number of sleeping
processes (e.g. slow spin). Also, it is difficult or impossible to
distinguish multiple sleeping threads within a process from separate sleeping
processes.
ACTION:
These fields should be removed.
--------------------------------------------------------------------------
@ 23.2 c 32
32: Section 23.2 page 201 line(s) 336
EDITORIAL COMMENT:
The type of the *notification parameter is missing. If our other objections
are not accepted, this should read ... struct sigevent *notification.
--------------------------------------------------------------------------
@ 23.2.7 o 33
33: Section 23.2.7 page 202-203 line(s) 370-426
OBJECTION:
In reference to D11 Unresolved Objection 140:
The function mq_setattr() provides the capability to dynamically modify the
message queue attributes, such as the message maximum size or maximum number
of messages. Although this functionality represents a higher degree of
flexibility, in our opinion, this flexibility does not justify the efficiency
burden imposed on the implementation that has to deal with the possibility of
dynamic sizing of the message queue objects. This represents a source for
more indeterminate time in the message queuing and dequeuing operations
(which could be concurrently executed with this dynamic reconfiguration of
the message queue) and a source of complexity and inefficiency for the
implementation.
Also, making the ability to set the max number of messages and max message
size implementation defined only makes this ability unusable by portable
applications, and points out that there is no true need for this ability.
ACTION:
Delete the mq_setattr() function, and make the queue attributes static.
--------------------------------------------------------------------------
@ 24 o 34
34: Section 24 page all line(s) all
OBJECTION:
Realtime files confuse the desired objective -- predictable performance --
with mechanisms that have historically been used to obtain predictable
performance from disks and/or file systems. This confusion is most evident in
the requirements laid on implementations to place data and to organize
descriptive information in particular ways. Current disk subsystem
technology, including SCSI, RAID, advanced striping, journaling, and recovery
technology render much of the low-level detail obsolescent if not obsolete.
The specification of low-level architecture and behavior stifle innovation
and leave little room to achieve the real goals of fast, predictable access
to data.
ACTION:
Delete this chapter. In the alternative, define in rationale only performance
metrics for vendor/technology comparison, and forward them to a benchmarking
group.
Alternatives using fcntl() to pass hints on access characteristics are
presented in other objections.
--------------------------------------------------------------------------
@ 24 o 35
35: Section 24 page 228-230 line(s) 578-625
OBJECTION:
rf_getbuf and rf_freebuf are new interface that are not needed. The usage can
be replaced with aligned versions of malloc as used in SunOS and other
systems.
ACTION:
Use this existing practice interface or delete this text.
--------------------------------------------------------------------------
@ 24 o 36
36: Section 24 page all line(s) all
OBJECTION:
The interfaces presented in Section 24 are overly complex to meet the stated
needs. The stat structure (defined in <stat.h>) can return the suggested I/O
blocksize in the field st_blksize. This allows determination on a
file-by-file basis.
The existing interface fcntl() can be used to advises the implementation
about the expected usage pattern for a file descriptor. The arguments that
fcntl() is not type-safe and should be discouraged are not compelling --
fcntl has been a general file management interface for many years, and
programmers have learned to deal with its impurities.
We differ with unresolved objection UO178.D11 in that we would use only
F_ADVISE, deleting F_DONTNEED and F_WILLNEED from that objection. We find
that the use of struct flock is unnecessary overloading.
ACTION:
Follow the prescription in UO178.D11 with the exception of F_DONTNEED and
F_WILLNEED.
--------------------------------------------------------------------------
@ 24 o 37
37: Section 24 page all line(s) all
OBJECTION:
We partially join in unresolved objections UO168.D11, UO171.D11, UO177.D11,
and UO178.D11. So- called "direct I/O" does not belong here. It is
disingenuous to claim (response to UO171.D11) that buffering the requests
anyway is an acceptable implementation. We challenge the technical reviewer
to give a cogent explanation of how manipulating the caching strategy and the
buffering strategy separately will give DETERMINISTIC and PORTABLE behavior.
This nonsense is not consistent with the claimed rationale for providing the
functionality, and tries to solve problems more appropriately solved by
standardized performance metrics/methodology and market pressures.
Moreover, capabilities for establishing similar functionality are already
available on existing UNIX Systems, e.g., use of raw disk partitions.
Complicating the I/O subsystem by adding per-file tunable buffering seems a
mistake.
ACTION:
Delete all references to "direct I/O" including these lines, definitions, and
rationale.
--------------------------------------------------------------------------
@ 24 c 38
38: Section 24 page 24.5 line(s) 234
EDITORIAL COMMENT:
If our objections relating to direct I/O are accepted, direct I/O is not used
in normative text, so this reference in the rationale should be deleted.
ACTION:
Delete lines 785-787.
--------------------------------------------------------------------------
@ 24 o 39
39: Section 24 page all line(s) all
OBJECTION:
We join in unresolved objections UO169.D11, 170-175, 179, and 180.
The reviewer's response to UO170.D11 adds useful information on some existing
systems that support "these facilities." The reviewer later mentions that
Digital has implemented D9 interfaces on a version of VMS, which further
weakens the claim that "these facilities" are necessary and broadly
supported. The dismissal of "realtime file systems" ignores the typical
implementation of files on modern operating systems using a Virtual File
System sort of architecture. The mixing of multiple types of files in a
directory hierarchy may preclude a high performance implementation and may,
in fact, affect all uses of files due to the support of so-called "realtime
files."
The argument in UO172.D11 is compelling. Not only are the facilities
insufficient to meet the claimed need, they cannot be made complete by
breaking up the capabilities buffer.
The reviewer's response to UO173.D11 is identical to that for UO172.D11, and
does not address the point of UO173. What portable actions can be taken by an
application? The capabilities buffer is certainly "a zoo" even after its
separation. The syntactic expression does not serve to hide semantic
(over-)complexity.
We have observed elsewhere that the 'aligned allocator' rf_getbuf should be
replaced with an aligned malloc as used in SunOS. (UO174.D11)
UO175.D11 and the essentially identical UO179.D11 give additional support to
our general comments on this Section.
ACTION:
Delete this chapter. Forward the performance metrics to a standards and/or
benchmarking group. (Retain the benchmarks in the rationale if desired.)
--------------------------------------------------------------------------
@ 24.3 o 40
40: Section 24.3 page 228 line(s) 578-625
OBJECTION:
The functions rf_getbuf() and rf_freebuf() should be compatible with existing
practice for aligned allocation.
ACTION:
Replace these names with valloc() as valloc(size) does an aligned allocation.
--------------------------------------------------------------------------
--
Robert L. Knighten | knighten@ssd.intel.com
Intel Supercomputer Systems Division |
15201 N.W. Greenbrier Pkwy. | (503) 629-4315
Beaverton, Oregon 97006 | (503) 629-9147 [FAX]
Volume-Number: Volume 27, Number 66
From std-unix-request@uunet.UU.NET Thu Apr 2 18:59:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05230; Thu, 2 Apr 92 18:59:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27287; Thu, 2 Apr 92 18:58:58 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <stephe@mks.com>
Subject: Re: Is POSIX a waste?
Message-Id: <1992Apr2.234909.18284@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net> <1992Mar31.212031.4967@uunet.uu.net> <1992Apr2.025846.29245@uunet.uu.net>
Date: Thu, 2 Apr 1992 20:42:22 GMT
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: stephe@mks.com (Stephen Walli)
In <1992Apr2.025846.29245@uunet.uu.net> tg@utstat.toronto.edu (Tom Glinos) writes:
>At the risk of being flamed back into the stone age I'll offer
>the opinion that the whole POSIX exercise has been a waste, for
>the following reasons.
No flames. :-)
I'll leave that to better flamers than I....
>[1] It's never been clear to me what the original POSIX proposals were
>supposed to define and accomplish. (What is the deliverable?)
Where/when are you referring to?
The /usr/group standard (POSIX.1's ancestor) had a very definate
scope/purpose. Likewise, POSIX.1 has a similar well defined scope/purpose.
For that matter, so does each and every piece of POSIX. They have all had
to go through the IEEE's review process for new proposed work items.
``This part of ISO/IEC 9945 defines a standard operating system interface
and environment to support application portability at the source-code
level. It is intended to be used by both applications developers and
system implementors.''
First page, first paragraph of the normative part of the POSIX.1 standard.
Similar statement as the first paragraph of POSIX.2, and so on.
Each document that is either a real standard, or fairly far along in the
development process is clearly declared.
>[2] This led to the ever widening number of groups. (More deliverables.)
No. Each project belonging to each working group serves a clearly defined
purpose. The breadth of the entire POSIX family of standards is very large,
but then the
book shelf space of a lot of operating systems User/Programmer documentation
can be considerable as well. (VMS's historical ``wall of orange'' for
instance.)
>[3] Some groups then started to argue and propose interfaces that in
>some cases had never been widely implemented or thoroughly studied.
Yep. Happens. Which is why there is a consensus based process in place to
build de jure standards. And there are people who regularly try to
subvert it. Also happens. Other people try and make it work. Sooner or later
it all balances out. Sort of like the informal consensus process which
surrounds the formal one.
P.J. Plauger writing about the politics of standards
[specifically the C standard] talked about good politics (when things are
going your way) versus ``Damned'' politics (when you're losing the fight.)
It's part of the process. But then it's part of any process where there are
a lot of people with a diverse set of experiences trying to build
something. [No ``blind men identifying an elephant'' jokes, please.]
And sometimes you lose. Hopefully, they aren't in places that will break
the standard badly enough to cast into doubt the entire standard or the
process that built it.
>[4] Some groups have let company and market pressures direct what should
>be an exercise in common sense and good engineering.
There are rules in the IEEE standards process to do with the balance
of membership in working groups (building draft documents) and balloting
groups (commenting on those drafts). They cannot be heavily weighted
towards Users OR Vendors.
There is a balance involved between users (wanting the sun and the stars) and
the vendors who can build something efficient (that will get you to the moon.)
Somewhere in the middle lies reality.
It's all about market pressure and economics at some level. If you want
great solutions based on ``common sense and good engineering'', live in a
research lab, which is probably the closest you'll get to such a perfect
world.
>It's been a bit more than a year since I looked at any POSIX document.
>If memory serves me correctly it's been about 5 years since the first
>document was tabled.
IEEE 1003.1-1988
>Has nothing been voted on?
IEEE 1003.1-1990 == ISO/IEC 9945-1:1990
IEEE 1003.3-1991
In ballot:
POSIX.2 *
POSIX.2a *
POSIX.3.1
POSIX.4 *
POSIX.4a
POSIX.5 *
POSIX.6
POSIX.9 *
POSIX.13
* -- Optimistically, almost done.
>When will it all end?
Wont. Standards change as technology changes. Not as rapidly, but they change.
New standards are added. Out-of-date standards are removed. Bad standards die.
>"Life is so much more meaningful if you take the time to hunt down and
> strangle twits who post blather to inappropriate newsgroups." Henry Spencer
Yes.
Cheers,
stephe
``So there *is* a God. What's your point?''
Volume-Number: Volume 27, Number 67
From std-unix-request@uunet.UU.NET Fri Apr 3 05:44:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA07895; Fri, 3 Apr 92 05:44:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21866; Fri, 3 Apr 92 05:44:53 -0500
Newsgroups: comp.std.unix
From: Andy Tanenbaum <ast@cs.vu.nl>
Subject: Query about POSIX rmdir system call
Message-Id: <1992Apr3.101844.23646@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Date: Fri, 3 Apr 1992 10:05:19 GMT
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: ast@cs.vu.nl (Andy Tanenbaum)
Does anyone know what the following program is supposed to do according
to P1003.1 and why? If the rmdir works, how can things like this be
implemented in general?
main()
{
#include <unistd.h>
mkdir ("D", 0777);
rmdir("D/.");
}
Andy Tanenbaum (ast@cs.vu.nl)
Volume-Number: Volume 27, Number 68
From std-unix-request@uunet.UU.NET Fri Apr 3 16:27:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13495; Fri, 3 Apr 92 16:27:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22614; Fri, 3 Apr 92 16:27:29 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: Is POSIX a waste?
Message-Id: <1992Apr3.211145.18029@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <1992Mar31.212031.4967@uunet.uu.net> <1992Apr2.025846.29245@uunet.uu.net> <1992Apr2.234909.18284@uunet.uu.net>
Date: Fri, 3 Apr 1992 10:29:26 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1992Apr2.234909.18284@uunet.uu.net> stephe@mks.com (Stephen Walli) writes:
>There is a balance involved between users (wanting the sun and the stars) and
>the vendors who can build something efficient (that will get you to the moon.)
>Somewhere in the middle lies reality.
So, the standards drop you into the asteroid belt?
Seriously, a good standard (one that canonicalized proven principles)
serves as a platform for further development, while a bad standard
(one that locks users into inferior technological solutions) serves
to stifle innovation. In the opinion of many, several of the newer
POSIX standards fall into the latter category. And they cannot just
be ignored, because both users and vendors have made advance
commitments to adhere to any and all such standards. Thus even bad
standards leave an indelible mark on computing.
Volume-Number: Volume 27, Number 69
From std-unix-request@uunet.UU.NET Fri Apr 3 16:27:33 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13536; Fri, 3 Apr 92 16:27:33 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22653; Fri, 3 Apr 92 16:27:38 -0500
Newsgroups: comp.std.unix
From: Cameron Simpson <cameron@spectrum.cs.unsw.oz.au>
Subject: Re: 1003.2a on comments in the shell
Message-Id: <1992Apr3.211313.18144@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: CS&E Computing Facility, Uni Of NSW, Oz
References: <1992Mar30.205758.2699@uunet.uu.net> <1992Mar31.024454.23050@uunet.uu.net>
Date: Sat, 4 Apr 1992 03:11:13 GMT
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: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
djm@eng.umd.edu (David J. MacKenzie) writes:
>> What does
>> echo a # b c
>> produce if typed at an interactive shell? There is one sh-style shell out
>> in the wide world that will echo 'a # b c' instead of just 'a' and I'd like
>> to know if this behavior is POSIX-compiliant.
[...]
>The only explicit mention of `#' for the shell in p1003.2a is in the
>description of the Vi editing mode.
I hope not. Every Bourne shell I've ever used considered that any word
commencing with an unquoted # introduces a comment extending through until
the end of the line. If POSIX breaks this (even in interactive mode) lots
of people will be pissed. Me for one.
- Cameron Simpson
cameron@cs.unsw.oz.au
P.S. Consider the chaos when it's no longer safe to cat a script and
cut/paste some of it into some shell window to get something done.
Not a great example, but convenient and not uncommon in a windowing
environment. Changing the rules for interactive mode is something to
approach with fear and trepidation.
Volume-Number: Volume 27, Number 70
From std-unix-request@uunet.UU.NET Fri Apr 3 16:27:39 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13543; Fri, 3 Apr 92 16:27:39 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22686; Fri, 3 Apr 92 16:27:45 -0500
Newsgroups: comp.std.unix
From: Fred Zlotnick <fred@mindcraft.com>
Subject: Re: Query about POSIX rmdir system call
Message-Id: <1992Apr3.211357.18216@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Apr3.101844.23646@uunet.uu.net>
Date: Fri, 3 Apr 1992 18:21:49 GMT
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: fred@mindcraft.com (Fred Zlotnick)
In article <1992Apr3.101844.23646@uunet.uu.net> ast@cs.vu.nl (Andy Tanenbaum) writes:
>Does anyone know what the following program is supposed to do according
>to P1003.1 and why? If the rmdir works, how can things like this be
>implemented in general?
>
> main()
> {
> #include <unistd.h>
>
> mkdir ("D", 0777);
> rmdir("D/.");
> }
First, my personal opinion: The directory "D" in the current directory
(the one just created by the mkdir() call) should be removed. The relevant
clause in 1003.1-1990 is 2.3.6, "pathname resolution", which says in part:
Pathname resolution is performed for a process to resolve a
pathname to a particular file in a file hierarchy...
Each filename in the pathname is located in the directory
specified by its predecessor.... If the pathname does not
begin with a slash, the predecessor of the first filename
of the pathname is taken to be the current working directory
of the process...
The special filename, dot, refers to the directory specified
by its predecessor.
Collective these imply (IMHO) that the pathname "D/." resolves to "D" in
the current directory. However, as Bob Lenk once said in this newsgroup,
"It is worth pointing out that official interpretations of an IEEE
standard can only be issued by the IEEE."
Having said all that, I tried this on six different systems, at least three
of which claim to be POSIX.1 conforming. It failed on all of them, with
errno = EINVAL on five of the six. EINVAL is not given as one of the errno
values for any error specified by POSIX.1.
The P1003.3.1 Draft 13 test assertions for clause 2.3.6 specify behavior
for rmdir (among other functions) for pathnames that have a "." as an
initial component or an intermediate component, but not as a final component.
That's no help. I think it's time for an official interpretation.
Incidentally, the 0777 in the mkdir call is not POSIX-portable. It will,
of course, work on all known systems (known to me, anyway) but the ugly
construct (mode_t)(S_IRWXU | S_IRWXG | S_IRWXO) is its POSIX-portable
replacement.
----
Fred Zlotnick | POSIX is coming! POSIX is coming!
fred@mindcraft.com | -- Stephen Walli
...!{uupsi,ames}!mindcrf!fred |
#include <std/disclaimer> |
Volume-Number: Volume 27, Number 71
From std-unix-request@uunet.UU.NET Sat Apr 4 16:02:40 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA22601; Sat, 4 Apr 92 16:02:40 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16124; Sat, 4 Apr 92 16:02:45 -0500
Newsgroups: comp.std.unix
From: Chuck Karish <karish@mindcraft.com>
Subject: Re: Is POSIX a waste?
Message-Id: <1992Apr4.204642.6108@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
References: <1992Mar31.024454.23050@uunet.uu.net> <1992Mar31.212031.4967@uunet.uu.net> <1992Apr2.025846.29245@uunet.uu.net>
Date: Fri, 3 Apr 1992 00:38:56 GMT
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 article <1992Apr2.025846.29245@uunet.uu.net> tg@utstat.toronto.edu
(Tom Glinos) writes:
>[1] It's never been clear to me what the original POSIX proposals were
>supposed to define and accomplish. (What is the deliverable?)
The "original POSIX proposals" were to codify existing
practice on UNIX and UNIX-like systems in a vendor-neutral
form. The deliverable is the POSIX.1 standard (ISO/IEEE
9945-1, 1990).
>[2] This led to the ever widening number of groups. (More deliverables.)
That's the price of success. Vendor-neutral, standard
specifications were found to be desirable in fields beyond
the scope of POSIX.1.
>[3] Some groups then started to argue and propose interfaces that in
>some cases had never been widely implemented or thoroughly studied.
Some of this was necessary because existing practice
included conflicting implementations, some of it was
necessary because existing practice was based on incomplete
or non-extensible abstractions, and some was gratuitous.
It's a bit of an exaggeration to blow this issue up and say
that it invalidates the POSIX standards process.
>[4] Some groups have let company and market pressures direct what should
>be an exercise in common sense and good engineering.
This complaint contradicts [3], above. The cases where
POSIX committees have been criticized for being too
innovative have resulted from attempts to use common
sense and engineering judgement where others would have
preferred simple description of existing implementations,
which are blessed by the companies that own them and
by the marketplace (installed base).
>If memory serves me correctly it's been about 5 years since the first
>document was tabled. Has nothing been voted on?
POSIX.1 has been a standard since August, 1988. POSIX.3
has been a standard for a little more than a year.
>When will it all end?
When the market for portable software disappears.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 27, Number 72
From std-unix-request@uunet.UU.NET Sun Apr 5 17:48:57 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05321; Sun, 5 Apr 92 17:48:57 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21962; Sun, 5 Apr 92 17:48:55 -0400
Newsgroups: comp.std.unix
From: Andy Tanenbaum <ast@cs.vu.nl>
Subject: Query about implementing FIFOs
Message-Id: <1992Apr5.213418.28871@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Date: Sun, 5 Apr 1992 21:08:56 GMT
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: ast@cs.vu.nl (Andy Tanenbaum)
Suppose a process opens (an empty) FIFO and writes some data to it.
Then it forks. The parent goes to sleep for a while, holding the FIFO
open. The child reads 5 bytes, then closes the FIFO. Then it opens the
FIFO again and reads 5 more bytes.
I presume POSIX requires that the second read return bytes 5-9 of the
original write, but how can this be implemented in a reasonable way?
There is no place in the i-node to keep track of the current file position,
and copying the FIFO to shift everything down 5 bytes doesn't sound like
much fun. Trying to figure out where the start of data is from the parent's
file pointer doesn't help, and besides, if the parent had closed too, that
wouldn't be there. How is this normally implemented?
Andy Tanenbaum (ast@cs.vu.nl)
Volume-Number: Volume 27, Number 73
From std-unix-request@uunet.UU.NET Wed Apr 8 02:17:06 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24034; Wed, 8 Apr 92 02:17:06 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA11557; Wed, 8 Apr 92 02:17:04 -0400
Newsgroups: comp.std.unix
From: John Gottschalk <john@citr.uq.oz.au>
Subject: threads library
Message-Id: <1992Apr8.060502.13348@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Prentice Centre, University of Queensland
Date: Wed, 8 Apr 1992 05:26:50 GMT
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: john@citr.uq.oz.au (John Gottschalk)
I am considering using the SUN light-weight process package (a threads library)
for some software development. I would like to know if there are
any standards for a threads library, so that the software can be fairly
portable. Do SVR4 or OSF offer a threads library?
-- regards, John Gottschalk
John Gottschalk (john@citr.uq.oz)
Centre for Information Technology Research,
The University of Queensland, 4072,
Brisbane, Queensland, Australia,
+61 7 365 4321 (phone), +61 7 365 4399 (fax)
Volume-Number: Volume 27, Number 74
From std-unix-request@uunet.UU.NET Wed Apr 8 02:22:26 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24112; Wed, 8 Apr 92 02:22:26 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12137; Wed, 8 Apr 92 02:22:21 -0400
Newsgroups: comp.std.unix
From: Andrew Josey <andrew@uel.co.uk>
Subject: submission for comp.std.unix
Message-Id: <1992Apr8.060636.13488@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Tue, 7 Apr 1992 15:42:00 GMT
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: andrew@uel.co.uk (Andrew Josey)
X/OPEN USERS GROUP MEETING
DATE: May 21st 1992
VENUE: X/Open offices Washington DC, USA
X/Open is running a series of one day user group meetings to provide
information and announcements on the X/Open branding programme
and the use of VSX (the Verification Suite for X/Open).
The second of these meetings will take place at X/Open's offices in
Washington D.C. on May 21st.
All prospective users and interested parties are invited to attend.
Attendees will also include current VSX licensee's, distributors, and X/Open
company users.
* DRAFT AGENDA
0930-10.00 Welcome and introductions James Andrews
1000-1100 VSX its development and implementation Tom Norris
Tom will outline the VSX development process, and explain in simple
terms how VSX works. Tom will also give a brief tutorial on the Test
Environment Toolkit and its role in future test strategy.
1100-1200 Branding UNIX System V Release 4 Andrew Josey
Andrew will relate his experience in branding UNIX SVR4. His talk
will include illustrations of the practical problems of using VSX for testing
prior to applying for the brand.
1200-1300 Making an application for branding Jenny Wilkinson
Jenny will explain how to put together a branding application that meets
X/Open requirements. She will outline the activities she undertakes in
processing the branding application and the typical problems encountered
and how they can be avoided.
1300-1400 Lunch
1400-1500 Test tool quality assurance and James Andrews
test developments.
James will outline the quality assurance techniques used by X/Open to
qualify test tools prior to their release. He will summarise all the current
release programs including a description of the test technology currently
under development. He will also explain the quality assurance methodologies
and procedures associated with branding to deliver to Users the
confidence in the conformity of branded products.
1500-1600 XPG4 branding and application James de Raeve
registration launch
James will explain X/Open's future plans for the branding program, in
particular the launch of XPG4. He will highlight the expected differences
between the XPG3 and XPG4 brands. James will also explain the application
registration scheme.
1600-1700 A test centre perspective TBD
An X/Open test centre will present their experiences in the
distribution of VSX and formal testing.
1700-1730 Questions and answers All Speakers
All speakers will allow some time for questions, however this session
gives you an opportunity to ask any burning question not answered
earlier.
1730-1745 Summing up and Close of meeting James Andrews
* List of Speakers
Tom Norris is product manager of VSX at X/Open's VSX developer and
manufacturer, UniSoft
Andrew Josey manages the branding of UNIX System Laboratories'
products including System V Release 4. He is the UNIX International
representative at the X/Open Verification Working Group.
Jenny Wilkinson is X/Open's branding administrator. She manages all
aspects of the processing of branding applications.
James Andrews is X/Open's Conformance Quality Manger. He is
responsible for the quality of the branding program and project manages
all test tool procurements and developments.
James de Raeve is X/Open's Conformance Strategy Manager. He is
responsible for all aspects of the branding programme and in particular its
direction and development
* TO RESERVE A PLACE
Lunch will be provided and there will be a fee for attendance of US$350.
Please let Anna Tomasello at X/Open know if you would like us
to reserve a place for you on this event. Closing date for
applications is Friday May 8th.
Anna Tomasello X/Open Company Limited
Technical Administrator Apex Plaza, Forbury Road
EMail:a.tomasello@xopen.co.uk Reading, England, RG1 1AX
FAX: +(44) (0)734 500110 Tel: +(44) (0)734 508311
Volume-Number: Volume 27, Number 74
From std-unix-request@uunet.UU.NET Wed Apr 8 02:22:28 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24117; Wed, 8 Apr 92 02:22:28 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12142; Wed, 8 Apr 92 02:22:24 -0400
Newsgroups: comp.std.unix
From: Andrew Josey <andrew@uel.co.uk>
Subject: submission for comp.std.unix
Message-Id: <1992Apr8.060734.13595@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Tue, 7 Apr 1992 15:42:00 GMT
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: andrew@uel.co.uk (Andrew Josey)
X/OPEN USERS GROUP MEETING
DATE: May 21st 1992
VENUE: X/Open offices Washington DC, USA
X/Open is running a series of one day user group meetings to provide
information and announcements on the X/Open branding programme
and the use of VSX (the Verification Suite for X/Open).
The second of these meetings will take place at X/Open's offices in
Washington D.C. on May 21st.
All prospective users and interested parties are invited to attend.
Attendees will also include current VSX licensee's, distributors, and X/Open
company users.
* DRAFT AGENDA
0930-10.00 Welcome and introductions James Andrews
1000-1100 VSX its development and implementation Tom Norris
Tom will outline the VSX development process, and explain in simple
terms how VSX works. Tom will also give a brief tutorial on the Test
Environment Toolkit and its role in future test strategy.
1100-1200 Branding UNIX System V Release 4 Andrew Josey
Andrew will relate his experience in branding UNIX SVR4. His talk
will include illustrations of the practical problems of using VSX for testing
prior to applying for the brand.
1200-1300 Making an application for branding Jenny Wilkinson
Jenny will explain how to put together a branding application that meets
X/Open requirements. She will outline the activities she undertakes in
processing the branding application and the typical problems encountered
and how they can be avoided.
1300-1400 Lunch
1400-1500 Test tool quality assurance and James Andrews
test developments.
James will outline the quality assurance techniques used by X/Open to
qualify test tools prior to their release. He will summarise all the current
release programs including a description of the test technology currently
under development. He will also explain the quality assurance methodologies
and procedures associated with branding to deliver to Users the
confidence in the conformity of branded products.
1500-1600 XPG4 branding and application James de Raeve
registration launch
James will explain X/Open's future plans for the branding program, in
particular the launch of XPG4. He will highlight the expected differences
between the XPG3 and XPG4 brands. James will also explain the application
registration scheme.
1600-1700 A test centre perspective TBD
An X/Open test centre will present their experiences in the
distribution of VSX and formal testing.
1700-1730 Questions and answers All Speakers
All speakers will allow some time for questions, however this session
gives you an opportunity to ask any burning question not answered
earlier.
1730-1745 Summing up and Close of meeting James Andrews
* List of Speakers
Tom Norris is product manager of VSX at X/Open's VSX developer and
manufacturer, UniSoft
Andrew Josey manages the branding of UNIX System Laboratories'
products including System V Release 4. He is the UNIX International
representative at the X/Open Verification Working Group.
Jenny Wilkinson is X/Open's branding administrator. She manages all
aspects of the processing of branding applications.
James Andrews is X/Open's Conformance Quality Manger. He is
responsible for the quality of the branding program and project manages
all test tool procurements and developments.
James de Raeve is X/Open's Conformance Strategy Manager. He is
responsible for all aspects of the branding programme and in particular its
direction and development
* TO RESERVE A PLACE
Lunch will be provided and there will be a fee for attendance of US$350.
Please let Anna Tomasello at X/Open know if you would like us
to reserve a place for you on this event. Closing date for
applications is Friday May 8th.
Anna Tomasello X/Open Company Limited
Technical Administrator Apex Plaza, Forbury Road
EMail:a.tomasello@xopen.co.uk Reading, England, RG1 1AX
FAX: +(44) (0)734 500110 Tel: +(44) (0)734 508311
[ Apologies if this gets out twice -- mod ]
Volume-Number: Volume 27, Number 75
From std-unix-request@uunet.UU.NET Thu Apr 9 17:14:22 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA07962; Thu, 9 Apr 92 17:14:22 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA20173; Thu, 9 Apr 92 17:14:28 -0400
From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: comp.std.unix
Subject: Re: Query about implementing FIFOs
Message-Id: <1992Apr9.193728.27989@uunet.uu.net>
Article-I.D.: uunet.1992Apr9.193728.27989
References: <1992Apr5.213418.28871@uunet.uu.net>
Organization: U of Toronto Zoology
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 Apr 92 16:58:13 GMT
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)
>Submitted-by: ast@cs.vu.nl (Andy Tanenbaum)
>There is no place in the i-node to keep track of the current file position,
>and copying the FIFO to shift everything down 5 bytes doesn't sound like
>much fun. Trying to figure out where the start of data is from the parent's
>file pointer doesn't help, and besides, if the parent had closed too, that
>wouldn't be there. How is this normally implemented?
Note that 6.3.1.2 says that if all file descriptors associated with a FIFO
have been closed, any remaining data goes away. The issue arises only if
somebody has kept the FIFO open, so the usual approach is for the kernel
to retain some extra information in core for an *open* FIFO. Andy is
correct that file pointers aren't useful, if only because there can be
more than one of them if several processes are involved; the extra
information has to be associated with the (in-core) inode, not with a
particular customer.
--
GCC 2.0 is to C as SVR4 is to Unix. | Henry Spencer @ U of Toronto Zoology
-Dick Dunn | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 27, Number 76
From std-unix-request@uunet.UU.NET Thu Apr 9 18:58:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA12047; Thu, 9 Apr 92 18:58:01 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19823; Thu, 9 Apr 92 18:58:04 -0400
Newsgroups: comp.std.unix
From: Bob Lenk <rml@hpfcdc.fc.hp.com>
Subject: Re: Report on POSIX.6, Jan. 1992
Message-Id: <1992Apr9.224808.9753@uunet.uu.net>
Originator: sef@ftp.UU.NET
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Technologies, Inc
References: <1992Apr2.025223.27860@uunet.uu.net>
Date: Thu, 9 Apr 1992 22:45:35 GMT
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: rml@hpfcdc.fc.hp.com (Bob Lenk)
In article <1992Apr2.025223.27860@uunet.uu.net> stephe@mks.com (Stephen Walli)
writes:
> Taken to an extreme, this means that regardless of the
> ballot pool size, if 3 people vote affirmative, 1 votes
> negative and the rest abstain, the initiative passes. The
> moral of the story is: abstain only as a last resort, there
> may be deleterious side effects.
While this is true, I wouldn't necessarily draw the conclusion that I
infer (vote negative rather than abstain). Remember that a negative
ballot must contain specific objections which, if addressed, would make
the ballot affirmative. Thus a negative ballot is actually an
affirmative response for the subsequent ballot with preconditions. In
other words, a negative ballot which doesn't cover all of its
submitter's real objections to the standard could have even more
"deleterious side effects".
Perhaps the conclusion I inferred was not intended. Another possible
conclusion is "do not submit a ballot rather than abstain". I agree
that it makes sense not to join a balloting group rather than to join
and abstain. If one has chosen to join, I think it is appropriate to
submit a ballot.
Bob Lenk
rml@fc.hp.com
{uunet,hplabs}!fc.hp.com!rml
Volume-Number: Volume 27, Number 77
From std-unix-request@uunet.UU.NET Mon Apr 13 19:41:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA20036; Mon, 13 Apr 92 19:41:32 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA09275; Mon, 13 Apr 92 19:41:24 -0400
From: Joseph Berry <berry@socrates.umd.edu>
Newsgroups: comp.std.unix
Subject: Re: threads library
Message-Id: <sd58rINNbb@ftp.UU.NET>
Article-I.D.: ftp.sd58rINNbb
References: <1992Apr8.060502.13348@uunet.uu.net>
Organization: UUNET Technologies, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 Apr 92 23:25:15 GMT
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: berry@socrates.umd.edu (Joseph Berry)
john@citr.uq.oz.au (John Gottschalk) writes:
>Submitted-by: john@citr.uq.oz.au (John Gottschalk)
>I am considering using the SUN light-weight process package (a threads library)
>for some software development. I would like to know if there are
>any standards for a threads library, so that the software can be fairly
>portable. Do SVR4 or OSF offer a threads library?
OSF offers a threads library. Furthermore, there is a pthreads "standard"
(not yet approved) POSIX 1003.4a.
Joe Berry
Strategic Software Group, Ltd., 3402 Shelburne Rd, Baltimore, MD 21208
E-mail: joe@ssgltd.com or uunet!ssgltd!joe
Phone: 410-764-5668; Fax: 410-358-2106; Pager: 410-796-6861
Volume-Number: Volume 27, Number 78
From std-unix-request@uunet.UU.NET Tue Apr 14 21:09:18 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA11897; Tue, 14 Apr 92 21:09:18 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24130; Tue, 14 Apr 92 21:09:14 -0400
From: Bob Robillard <duke@sunni.ctsd.bellcore.com>
Newsgroups: comp.std.unix
Subject: Mock Ballot on 1003.7.1, POSIX Printing
Message-Id: <sfrvuINNndt@ftp.UU.NET>
Organization: UUNET Technologies, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 92 00:05:18 GMT
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: duke@sunni.ctsd.bellcore.com (Bob Robillard)
IEEE P1003.7 POSIX is about to start a "mock ballot" of the
POSIX Print System Requirements. POSIX is a group of IEEE
sponsored standards defining a UNIX-like operating
environment. The System Administration Working Group
(1003.7) is the group responsible for system administration
standards (i.e. the type of operations traditionally found
in section 8 of the user manuals--fsck, lpc, mkfs, etc).
The document ready for mock ballot is 1003.7.1, Draft
Standard for Information Technology--Portable Operating
System Interface(POSIX)--System Adminstration
Interface/Printing.
A mock ballot is an unofficial, non-binding version of the
regular ballot procedures. It is performed to get early
feedback on the direction a standard is taking. 1003.7 has
adopted MIT's Palladium printing system as the base for its
printing standard, and one of the goals of this mock ballot
is to test the acceptability of this choice.
Even if you cannot fully participate in the mock ballot,
1003.7 would greatly appreciate feedback on the choice of
Palladium as the base for this document. While we would
appreciate extensive comments, a simple yes vote, or a no
vote with an explanation about why Palladium is not an
acceptable base, would be very helpful.
Please fill out the attached form should you wish to join
the mock ballot group.
Martin Kirk
Chair 1003.7
UNIX is a registered trademark of UNIX System Laboratories, Inc.
--------------------------cut here------------------------------
INVITATION TO JOIN P1003.7 MOCK BALLOT GROUP
The IEEE POSIX P1003.7 System Administration Working Group has
been developing the POSIX printing inteface, P1003.7.1. This
standard describes the requirements for printing and printing ad-
ministration. P1003.7 will be conducting a mock ballot of the
1003.7.1 starting May 14, 1992 and running until June 30, 1992.
The purpose of this ballot is to seek feedback on this work from
those interested parties who have been inside and outside the
development process and to prepare for the formal ballot which is
tentatively scheduled for the second half of 1992. If you pro-
vide an E-mail address, we will send the draft in Post Script
form via this method. If you require a hard copy of the draft,
we will make every effort to have it in the mail no later than
the start of balloting . Please indicate your desire to partici-
pate in this P1003.7.1 Mock Ballot by sending the following in-
formation:
Name:_____________________________________________________________
E-mail
address:__________________________________________________________
Company/Organization
Name:_____________________________________________________________
Address:__________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
Phone:____________________________________________________________
FAX:______________________________________________________________
My primary interest category relative to this Standard is:
(Check only one)
[ ] General Interest
[ ] User
[ ] Producer
I would like the draft in the following format:
(Check only one)
[ ] Post Script via Email
[ ] Hard copy via U.S. mail
Send this information by Wednesday, April 29, 1992 to:
Bob Robillard Voice: 908-699-2249
Bellcore FAX: 908-336-2827
RRC 1D229 duke@cc.bellcore.com
444 Hoes Lane
Piscataway, New Jersey 08854
Thank you in advance for your consideration of this effort.
Sincerely,
Martin Kirk, Chair IEEE P1003.7
Volume-Number: Volume 27, Number 79
From std-unix-request@uunet.UU.NET Wed Apr 15 16:49:34 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10870; Wed, 15 Apr 92 16:49:34 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA06335; Wed, 15 Apr 92 16:49:32 -0400
From: Michael Joosten <joost@ori.cadlab.de>
Newsgroups: comp.std.unix
Subject: Re: threads library
Message-Id: <si30aINNcgv@ftp.UU.NET>
Article-I.D.: ftp.si30aINNcgv
References: <sd58rINNbb@ftp.UU.NET>
Reply-To: joost@cadlab.uni-paderborn.de
Organization: UUNET Communications
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 92 20:17:14 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: joost@ori.cadlab.de (Michael Joosten)
In article <sd58rINNbb@ftp.UU.NET>, berry@socrates.umd.edu (Joseph Berry)
writes:
>>I am considering using the SUN light-weight process package (a threads library)
>>for some software development. I would like to know if there are
>>any standards for a threads library, so that the software can be fairly
>>portable. Do SVR4 or OSF offer a threads library?
>OSF offers a threads library. Furthermore, there is a pthreads "standard"
>(not yet approved) POSIX 1003.4a.
The situation concerning threads libraries is currently a bit difficult.
Yes, OSF has POSIX pthread implementation in its DCE package. But it is
unclear how to get only OSF pthreads (which are in reality DEC's CMA (Concert
Multithread Architecture) threads) without all the DCE stuff around. For an
educational site it was rather cheap to join OSF an buy a DCE snapshot (200$ +
1000$), I don't know what they charge now.
Actually , SunSoft has apparently own plans on improving LWP. There is a paper
about this in a recent USENIX (Winter '91 ?) about Sun's further development
plus an interesting paper about how to take care of non-reentrant libraries.
USL? I don't kow, but I would like to hear a bit more about their intentions.
Probably there is something emerging, especially with Chorus and the
much-awaited MultiProcessing Release of SysVR4.
Since currently no vendor actually sells his Unix with a standardized pthreads
AND re-rentrant libraries (except OSF with OSF/1, but that's not a vendor),
the situation is actually a bit hosed: Many developers will face the task to
convert their existing/emerging multithreaded programs to pthreads, and this
could be not always easy. LWP, e.g., offers a yield() function which takes an
explicit LWP argument, thus leading developers to play scheduler-by-their-own
instead of relying on a built-in scheduler or sempahores/mutexes/condition
variables/messages. This nearly happened here, and pthread has of course no
such yield_to(xxx). An explicit yield_to() is fine for coroutines, but does
not make sense for real threads where the scheduler has more kowledge about
which (system) resource is blocked or ready (file descriptors,..) than the
programmer.
Anyway, without re-entrant libs (libc_r.a) there is IMHO not so much profit
with pthreads, since a premptive context change is mostly simulated with
SIGALRM and the finer-grained BSD timer functions. Since most libraries are
not built to cope with changing threads, you either must set 'guards' like
mutexes around a lot of (if not all) C library functions (most of the section
(3) stuff) or be extremly cautiously when coding your system. In the former
case, you will likely lose performance; imagine your program oftenly call libc
functions - every time the mutex has to be locked and released, maybe with an
additional set/reset of the signal mask (expensive system call!).
Well, this is my perspective, now nearly 5-6 months old. If there's something
radically changed, please let me know!
Michael Joosten | Tel. : (+49) (+) 5251-284 120
CADLAB | Fax : (+49) (+) 5251-284 140
Bahnhofstr. 32 | E-Mail: joost@cadlab.de
D-4790 Paderborn | ...!uunet!unido!cadlab!joost
FRG | Mass mail to: joost@pbinfo.uni-paderborn.de
Volume-Number: Volume 27, Number 80
From std-unix-request@uunet.UU.NET Wed Apr 15 17:49:07 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA18696; Wed, 15 Apr 92 17:49:07 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA25070; Wed, 15 Apr 92 17:49:04 -0400
From: Chris Flatters <cflatter@nrao.edu>
Newsgroups: comp.std.unix
Subject: Re: threads library
Message-Id: <si6vpINNdr3@ftp.UU.NET>
Article-I.D.: ftp.si6vpINNdr3
References: <si30aINNcgv@ftp.UU.NET> si30aINNcgv@ftp.UU.NET,
Reply-To: cflatter@nrao.edu
Organization: NRAO
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 92 21:25:13 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: cflatter@NRAO.EDU (Chris Flatters)
In article si30aINNcgv@ftp.UU.NET, joost@ori.cadlab.de (Michael Joosten) writes:
>Submitted-by: joost@ori.cadlab.de (Michael Joosten)
>Actually , SunSoft has apparently own plans on improving LWP. There is a paper
>about this in a recent USENIX (Winter '91 ?) about Sun's further development
>plus an interesting paper about how to take care of non-reentrant libraries.
Winter '91 is correct: "SunOS Multi-thread Architecture" by M. L. Powell et al.
I think that it is reprinted in "The SPARC Technology Papers".
The gist of the paper is that Sun have adopted a two-layer model for multi-
threading. At one level threads are implemented in a user-space library while
at the other light-weight processes are implemented in the kernel.
Chris Flatters
cflatter@nrao.edu
Volume-Number: Volume 27, Number 81
From std-unix-request@uunet.UU.NET Wed Apr 15 17:53:33 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19958; Wed, 15 Apr 92 17:53:33 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26804; Wed, 15 Apr 92 17:53:32 -0400
From: "Kathy A. DeMartini" <kdemarti@polyslo.csc.calpoly.edu>
Newsgroups: comp.std.unix
Subject: pls post comp.std.unix,comp.protocols.pup
Message-Id: <si86qINNeam@ftp.UU.NET>
Organization: UUNET Communications
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Apr 92 21:46:02 GMT
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: kdemarti@polyslo.csc.calpoly.edu (Kathy A. DeMartini)
I am looking for information concerning Express Technology Protocol
(XTP) or X/Open Transport interface (XTI) with respect to implementation
under Unix. XTP is a 3 level protocol for higher bandwidth versus OSI,
in which TCP/IP or others would be implemented. This is an emerging
standard.
If you could mail me articles or information, it would be appreciated.
Pls e-mail direct versus posting, I will summarize and post whatever
results in 2 weeks.
Thank you.
Volume-Number: Volume 27, Number 82
From std-unix-request@uunet.UU.NET Sun Apr 19 18:02:00 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05549; Sun, 19 Apr 92 18:02:00 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22464; Sun, 19 Apr 92 18:01:47 -0400
From: "Robert L. Knighten" <knighten@intel.com>
Newsgroups: comp.std.unix
Subject: POSIX P1003.4a (Pthreads) Common Reference Ballot
Message-Id: <ssnddINN2h9@ftp.UU.NET>
Reply-To: Bob Knighten <knighten@ssd.intel.com>
Organization: Intel Supercomputer System Division, Beaverton, OR
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 19 Apr 92 21:06:53 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: knighten@intel.com (Robert L. Knighten)
Draft 6 of the P1003.4a (Threads Extension) draft standard is in its second
ballot (first reballot.) This ballot is due at the IEEE Standards Office on
May 1.
The following group met and drafted a Common Reference Ballot which
we hope will be considered by other members of the ballot group before they
submit their own ballots. Our CRB is included at the end of this message.
The CRB will be submitted as the first 70 items in the ballot of
Robert L. Knighten of Intel Supercomputer Systems Division.
Nawaf Bitar Kubota-Pacific
David Black Open Software Foundation
Bob Conti Digital Equipment Corporation
Bill Cox Unix Systems Laboratories
Michael Jones Carneige-Mellon University
Steve Kleiman SunSoft
Bob Knighten Intel Supercomputer Systems Division
Jim Pitcairn-Hill Open Software Foundation
Dave Plauger Hewlett-Packard
Paul Rabin Open Software Foundation
This CRB is also available in various forms (ASCII, postscript, troff) by
anonymous ftp from export.ssd.intel.com in the directory /pub/tmp/CRB.
==============================================================================
Robert L. Knighten P1003.4a/D6 Ballot 4/3/92
knighten@ssd.intel.com (503) 629-4315 FAX 629-9147
--------------------------------------------------------------------------
@ all o 1
1: Section all page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ all o 2
2: Section all page all line(s) all
OBJECTION:
The deletion of the POSIX.4 memory model leaves a void in terms of the
specification of memory access characteristics. While the CRB group
is not particularly enamored with the POSIX.4 memory model, we feel
something is required in this space.
ACTION:
Specify a memory model for POSIX.4a. You may contact Nawaf Bitar to
coordinate assistance in the development of a memory model.
--------------------------------------------------------------------------
@ 2 o 3
3: Section 2 page 2.2 line(s) 4
OBJECTION:
The term "allocation domain" does not clearly refer to a scheduling
allocation.
ACTION:
Change the defined term to "Scheduling Allocation Domain [Allocation
Domain]".
--------------------------------------------------------------------------
@ 2 o 4
4: Section 2 page 2.2 line(s) 5
OBJECTION:
The term "contention scope domain" does not clearly refer to a
scheduling contention scope.
ACTION:
Change the defined term to "Scheduling Contention Scope [Contention
Scope]".
--------------------------------------------------------------------------
@ 2.2 o 5
5: Section 2.2 page 5 line(s) 80-81
OBJECTION:
With the inclusion of the process shared attribute mutexes and other
synchronization primitives can be used in shared memory by more than
one processes.
ACTION:
Delete lines 80-81.
--------------------------------------------------------------------------
@ 2.2 o 6
6: Section 2.2 page 5 line(s) 98-99
OBJECTION:
The set of synchronous signal that can be generated is not limited to
the list in the text. For example SIGBUS.
ACTION:
Either correct the list or change it to the following:
The signals which may be generaed synchronously include SI-
GILL,
SIGFPE, ...
--------------------------------------------------------------------------
@ 2.2 o 7
7: Section 2.2 page 6 line(s) 104
OBJECTION:
"with a thread" doesn't make sense.
ACTION:
Change "with a thread" to "by a thread."
--------------------------------------------------------------------------
@ 2.2 o 8
8: Section 2.2 page 6 line(s) 115-116
OBJECTION:
It should be permissible to use the thread ID of a detached thread if
the application knows via programmed synchronization that the target
thread has not exited. Note that a thread cannot spontaneously exit
without calling pthread_exit(), being cancelled (and running the can-
cellation handlers), or the process exits.
ACTION:
Delete the sentence beginning "Detaching a thread also prohibits..."
or change it to indicate that if the application know via programmed
synchronization mechanisms that the thread has not exited then using
the thread ID is permissible.
--------------------------------------------------------------------------
@ 2.2.1.138,6 o 9
9: Section 2.2.1.138,6 page 4,79-101 line(s) 64-65,1-762
OBJECTION:
The terms global and local contention scope are misleading. [See ob-
jection ???.] The terms system and process contention scope are more
intuitive.
ACTION:
Change PTHREAD_SCOPE_GLOBAL to PTHREAD_SCOPE_SYSTEM. Change
PTHREAD_SCOPE_LOCAL to PTHREAD_SCOPE_PROCESS. Change all references
to `global contention scope' to `system contention scope'. Change all
references to `local contention scope' to `process contention scope'.
--------------------------------------------------------------------------
@ 2.2.1.139 o 10
10: Section 2.2.1.139 page 5 line(s) 66-69
OBJECTION:
The definition of "initial thread" is misleading, and a holdover from
older drafts with very different semantics. In particular, calling
the thread which results from fork() an initial thread is wrong with
respect to the current usage of the term in the draft.
ACTION:
Replace the definition of "initial thread" with "The first thread
which calls main() after an exec, or any thread resulting from a
fork() by an initial thread".
--------------------------------------------------------------------------
@ 2.6.2 o 11
11: Section 2.6.2 page 14 line(s) 388
OBJECTION:
The constant name "DATAKEYS_MAX" does not follow the pthreads naming
conventions.
ACTION:
Change the name to "PTHREAD_DATAKEYS_MAX". Similarly, change
"_POSIX_DATAKEYS_MAX" to "_POSIX_PTHREAD_DATAKEYS_MAX".
--------------------------------------------------------------------------
@ 3 o 12
12: Section 3 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 3 o 13
13: Section 3 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 3.3 o 14
14: Section 3.3 page 29-30 line(s) 408-444
OBJECTION:
The function pthread_exit() terminates a thread; if you have pthreads
at all, the fundamental management routines pthread_create(),
pthread_join, pthread_exit, and pthread_self are essential. Permit-
ting any of those functions to be optional in any way means that you
don't have threads that you can use. How can an application use the
fact that pthread_exit() fail? How can a function that cannot return
(line 438) "return 01 and set errno to the corresponding value"?
ACTION:
Delete all error return specification from the pthread_exit() specifi-
cation.
--------------------------------------------------------------------------
@ 3.3 o 15
15: Section 3.3 page 29-30 line(s) 412-471
OBJECTION:
The parameter name "status" is misleading. The actual use of the
pthread_exit parameter is the return value from the start_function ex-
ecuted by the thread.
ACTION:
Change the synopsis to
void pthread_exit( void *value_ptr);
--------------------------------------------------------------------------
@ 3.3 o 16
16: Section 3.3 page 30 line(s) 431-433,463-471
OBJECTION:
This return status makes no sense. The success or failure of a pro-
cess is not determined by whether the last thread to exit was de-
tached. The exit status for the process should be determined by the
parameter to an explicit _exit() call or the return value to main() as
specified in POSIX.1.
ACTION:
Delete lines 431-433 and 463-471.
--------------------------------------------------------------------------
@ 3.3 o 17
17: Section 3.3 page 30 line(s) 459-462
OBJECTION:
ANSI C does not generally require implementations to preserve integer
values across multiple typecasts. The example is non-portable and
should be deleted.
ACTION:
Delete text starting at "it is perfectly" and terminate the sentence.
--------------------------------------------------------------------------
@ 3.3.5.2, 7.3.3.2 o 18
18: Section 3.3.5.2, 7.3.3.2 page 29, 105 line(s) 425-427
OBJECTION:
Talking about main() and exit() under the pthread_exit() is extrane-
ous.
ACTION:
Change lines 425-427 to being a note, instead of normative text in the
pthread_exit() description. Also, move this text to the description
of _exit(), in section 7.3.3.2, where it belongs.
--------------------------------------------------------------------------
@ 3.4 o 19
19: Section 3.4 page 37 line(s) 643-652
OBJECTION:
Measuring overhead in units of the "null loop" is not portable as op-
timizing compilers can delete null loops entirely.
ACTION:
Delete this performance metric or restate it in terms of a computation
that takes a certain amount of time instead of iterations of the null
loop.
--------------------------------------------------------------------------
@ 3.4 o 20
20: Section 3.4 page 37 line(s) 654-660
OBJECTION:
Measuring overhead in units of the "null loop" is not portable as op-
timizing compilers can delete null loops entirely.
ACTION:
Delete this performance metric or restate it in terms of a computation
that takes a certain amount of time instead of iterations of the null
loop.
--------------------------------------------------------------------------
@ 4 o 21
21: Section 4 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 4 o 22
22: Section 4 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 4.4 o 23
23: Section 4.4 page 44-61 line(s) 85-676
OBJECTION:
There is currently no interface provided by which statically allocated
mutex and condition variable objects can be statically initialized.
Providing this ability would make self-initializing modules easier to
write, and would often make such self-initialization more efficient as
well.
Furthermore, there is substantial existing practice which provides
such interfaces, including Mach cthreads, Encore threads, Sun threads,
and others.
ACTION:
Provide new macros PTHREAD_MUTEX_INITIALIZER and
PTHREAD_COND_INITIALIZER which may be used in static declarations to
initialize mutexes and condition variables. The effect of:
static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
at compile time should be identical to the effect of:
static pthread_mutex_t m;
pthread_mutex_init(&m, NULL);
at run time. Similarly, the effect of:
static pthread_cond_t c = PTHREAD_COND_INITIALIZER;
at compile time should be identical to the effect of:
static pthread_cond_t c;
pthread_cond_init(&c, NULL);
at run time.
Also, add rationale similar to the following discussion supporting
this addition.
STATIC INITIALIZATION OF SYNCHRONIZATION OBJECTS:
Providing for static initialization of statically allocated synchroni-
zation objects allows modules with private static synchronization
variables to avoid run time initialization tests and overhead. Furth-
ermore, it simplifies the coding of self-initializing modules. Such
modules are common in C libraries, where for various reasons the
design called for self-initialization, instead of requiring an expli-
cit module initialization function to be called. An example use of
static initialization follows.
Without static initialization, a self-initializing routine foo() might
look like:
static pthread_once_t foo_once = PTHREAD_ONCE_INIT;
static pthread_mutex_t &foo_mutex;
void foo_init()
{
pthread_mutex_init(&foo_mutex, NULL);
}
void foo()
{
pthread_once(&foo_once, foo_init);
pthread_mutex_lock(&foo_mutex);
/* Do work */
pthread_mutex_unlock(&foo_mutex);
}
With static initialization, the same routine could be coded as:
static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER;
void foo()
{
pthread_mutex_lock(&foo_mutex);
/* Do work */
pthread_mutex_unlock(&foo_mutex);
}
Note that the static initialization both eliminates the need for the
initialization test inside pthread_once and the fetch of &foo_mutex to
learn the address to be passed to pthread_mutex_{lock, unlock}. Thus,
the code written is simpler on all machines, and will also be faster
on a large class of machines.
Yet people will rightly raise the performance question for machines
(such as the Sequent Balance) which require mutexes to be allocated
out of special memory. Such machines will actually have to have
mutexes and possibly condition variables contain pointers to the actu-
al hardware locks. For static initialization to work on such
machines, pthread_mutex_lock() will also have to test whether or not
the pointer to the actual lock has been allocated. If it hasn't it
will have to initialize it before use. This run time test in
pthread_mutex_lock would at first seem to be extra work. Yet notice
that in the above old example, pthread_once() was explicitly called in
application code for all implementations to test for mutex initializa-
tion -- in the new example the test is hidden inside
pthread_mutex_lock() only for those machines which need it. The over-
head for machines doing out-of-line mutex allocation is thus similar
for modules being implicitly initialized, where it's improved for
those doing mutex allocation entirely inline. The inline case is
thus made much faster and the out-of-line case is no worse.
Two further objections have been raised to static initialization of
synchronization objects for out-of-line implementations. First, an
extra test is required to see if the pointer has been initialized.
This might seem to add significant expense. On most machines this
would actually be implemented as a fetch of the pointer, testing the
pointer against zero, and then using the pointer if it has already
been initialized. While the test might seem to add extra work, the
extra cost of testing a register is usually negligible since no extra
memory references are actually done. As more and more machines pro-
vide caches, the real expenses are memory references, not instructions
executed.
Secondly, it is possible that threads would serialize contending for
initialization locks when attempting to finish initializing statically
allocated mutexes. (Such finishing would typically involve taking an
internal lock, allocating a structure, storing a pointer to the struc-
ture in the mutex, and releasing the internal lock.) First, many im-
plementations would reduce such serialization by hashing on the mutex
address. And second, such serialization can only occur a bounded
number of times. In particular, it can happen at most as many times
as there are statically allocated synchronization objects. Dynamical-
ly allocated objects would still be initialized via
pthread_mutex_init() or pthread_cond_init(). Finally, if this is a
true issue, static initialization can be avoided altogether by expli-
citly initializing all synchronization objects with the corresponding
pthread_*_init() functions.
In summary: (1) Static initialization provides a significant simplif-
ication for programmers of self-initializing modules. (2) Static ini-
tialization significantly improves performance for many implementa-
tions. (3) Static initialization will not significantly degrade per-
formance for any known implementations. Thus, facilities allowing for
static initialization of synchronization objects are included as part
of the threads interface.
--------------------------------------------------------------------------
@ 4.4 o 24
24: Section 4.4 page 48 line(s) 241-251
OBJECTION:
When a process maps a file that contains a process shared synchroniza-
tion variable it must not reinitialize it. Similarly, if a process has
an initialized synchronization variable in MAP_SHARED memory and
forks, it does not have to be reinitialized.
ACTION:
After line 251 add something like the following:
If a process shared mutex has previously been initialized by another
process, the application shall not reinitialize it.
--------------------------------------------------------------------------
@ 4.4 o 25
25: Section 4.4 page 55 line(s) 477-487
OBJECTION:
When a process maps a file that contains a process shared synchroniza-
tion variable it must not reinitialize it. Similarly, if a process has
an initialized synchronization variable in MAP_SHARED memory and
forks, it does not have to be reinitialized.
ACTION:
Add something like the following after line 487:
If a process shared condition variable has previously been initialized
by another process, the application shall not reinitialize it.
--------------------------------------------------------------------------
@ 4.4.7.6.1 o 26
26: Section 4.4.7.6.1 page 61 line(s) 681
OBJECTION:
ACTION:
Change "return successfully" to "return without an error".
--------------------------------------------------------------------------
@ 5 o 27
27: Section 5 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 5 o 28
28: Section 5 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 5.2 o 29
29: Section 5.2 page 73 line(s) 75-80
OBJECTION:
A standard pthread_key_delete() is needed for dynamically linked li-
braries to recover storage when they are unlinked. Many modern OS im-
plementations allow programatic runtime linking in of libraries.
ACTION:
Add pthread_key_delete(). The destructors should be called in each
thread. It is OK if the application id required to ensure that the
other thread-specific data function are not called simultaneously with
pthread_key_delete().
--------------------------------------------------------------------------
@ 5.2 o 30
30: Section 5.2 page 74 line(s) 103-107
OBJECTION:
Destructor functions must be allowed to call functions that can poten-
tially allocate thread-specific data, otherwise functions must be
specifically documented as callable from a destructor or not.
ACTION:
In order to accomplish this, destructor functions must be called re-
peatedly until all thread-specific data is destroyed. Lines 158-160
must also be deleted or modified.
--------------------------------------------------------------------------
@ 5.2 o 31
31: Section 5.2 page 75 line(s) 148
OBJECTION:
pthread_getspecific() should simply return the value instead of stor-
ing it through a pointer. This could substantially speed up a critical
function.
ACTION:
Change pthread_getspecific to:
void * pthread_getspecific(pthread_key_t key); If any error is
detected, NULL is returned.
--------------------------------------------------------------------------
@ 5.2 o 32
32: Section 5.2 page 75-76 line(s) 151-161
OBJECTION:
Since pthread_{s, g}etspecific may not work if the key is undefined
the standard should explicitly state that called either of these with
an uncreated or destroyed key is undefined. This explicitly prevents
the (erroneous) example in lines 246-255.
ACTION:
Add something like the following before line 161:
The effect of calling pthread_getspecific or
pthread_setspecific
with a key value that has not been created (or has been des-
troyed)
is unspecified.
--------------------------------------------------------------------------
@ 5.2 o 33
33: Section 5.2 page 76 line(s) 174-175
OBJECTION:
In implementations that support infinite amounts of thread-specific
data pthread_setspecific can allocate memory and must be able to re-
turn an error is memory is unavailable.
ACTION:
Add ENOMEM to the list of errors for pthread_setspecific.
--------------------------------------------------------------------------
@ 5.3 o 34
34: Section 5.3 page 77 line(s) 213-215
OBJECTION:
The text reads:
If second and subsequent calls to pthread_setspecific perform
differently than the first call, then these measurements shall
also be reported. In implementation that support an unbounded
amount of thread-specific data, this can cause an unbounded number of
measurements.
ACTION:
Delete this sentence or replace it with measurements of setting
storage for specified numbers of keys. It is probably best that these
be less than 32 keys since this is all a strictly conforming applica-
tion can depend on.
--------------------------------------------------------------------------
@ 5.3 o 35
35: Section 5.3 page 28-29 line(s) 363-407
OBJECTION:
Since there is a "detached" attribute to thread creation, there is no
longer very much motivation to include pthread_detach() as a separate
function. There is very little need to detach a thread on the fly,
since this is mostly known at thread create time when the thread ID is
stored. Making the initial thread be created "undetached" by default
means that it can be joined with, while the potential storage leak is
limited.
ACTION:
Delete pthread_detached(). Add the requirement that the initial thread
be created "undetached".
--------------------------------------------------------------------------
@ 6 o 36
36: Section 6 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 6 o 37
37: Section 6 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 6 o 38
38: Section 6 page all line(s) all
OBJECTION:
The use of realtime-centric nomenclature, and in particular
SCHED_OTHER, is confusing. SCHED_OTHER is simply a placeholder for
"some scheduling algorithm that may be different or not different from
SCHED_FIFO and SCHED_RR". This suggests both that SCHED_OTHER is a
name for some specific scheduling algorithm AND that SCHED_OTHER is a
name for some selectable scheduling algorithm that may be different
from SCHED_FIFO and SCHED_RR.
Unfortunately, SCHED_OTHER can't be both. The apparent meaning is of
some system-defined policy that is neither FIFO nor RR. A more ap-
propriate name is "SCHED_DEFAULT."
ACTION:
Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter.
--------------------------------------------------------------------------
@ 6 o 39
39: Section 6 page all line(s) all
OBJECTION:
The rationale in this chapter talks about many things, most of which
are not relevant to the scope of POSIX.4a. Sections 6.1.1.3 and 6.2.3
are particularly irrelevant, as they talk about scheduling on a
machine with allocation domain of size greater than one, which was
specifically excluded from the scope of scheduling by the working
group.
The text of section 6.2.3 is an attempt to extend the semantics of
uniprocessor scheduling to the multiprocessor domain in a way that ex-
cludes existing practice or renders the somewhat intuitive SCHED_FIFO
and SCHED_RR meaningless (line 214-216). One point made by previous
POSIX.14 coordination ballots and comments was that priority is less
meaningful in a multiprocessor. Line 217 overspecifies behavior.
ACTION:
Delete this chapter. Define the interactions of draft POSIX.4
scheduling behavior and pthreads in a separate document, or move the
contents of this chapter to a non-normative appendix clearly marked as
"Uniprocessor Thread Scheduling."
--------------------------------------------------------------------------
@ 6 o 40
40: Section 6 page all line(s) all
OBJECTION:
The rationale is excessively broad for the normative text in this
chapter. Rationale should explain the derivation and meaning of the
normative text; the Chapter 6 rationale goes far beyond that.
The most egregious examples are lines 110-118 (Rate Monotonic Schedul-
ing) and lines 704-739. The working group did not accept this text
even for a non-normative appendix, and including it in this draft or
any final standard based on this draft is excessive. The rationale is
not intended as a place to announce interfaces for "future updates"
when the working group did not find the interfaces acceptable for in-
clusion anywhere in the draft.
The presentation here amounts to an endorsement by POSIX of a research
effort and related projects by the current technical reviewer and his
colleagues, and inappropriate to normative or rationale text.
ACTION:
Delete lines 110-118 and 704-739 and any other references in the draft
that refer to rate monotonic scheduling or sporadic servers.
--------------------------------------------------------------------------
@ 6 o 41
41: Section 6 page all line(s) all
OBJECTION:
This chapter is beyond scope in references to multiprocessors and mul-
tiprocessor scheduling because the interfaces and uniprocessor tech-
niques are neither well-understood nor appropriate to multiprocessors.
The extensions to "scheduling domains of size greater than one" is fa-
tally flawed because they work either poorly or not at all on current
and near-future multiprocessor architectures such as the Stanford DASH
machine. These interfaces and techniques apply only to uniprocessors,
therefore they conflict with page 1 lines 25-27, and should be delet-
ed.
ACTION:
Delete Chapter 6.
--------------------------------------------------------------------------
@ 6.1 o 42
42: Section 6.1 page 80 line(s) 34
OBJECTION:
In POSIX, the concept of a "kernel entity" is misplaced. The proper
language would refer instead to a "process."
ACTION:
Change "kernel entity (process)" to "process".
--------------------------------------------------------------------------
@ 6.2.2 o 43
43: Section 6.2.2 page 83 line(s) 186-189
OBJECTION:
The definition of global contention scope ignores the concept of allo-
cation domain. Resource contention only makes sense within an alloca-
tion domain, as indicated by lines 202-204: Allocation domain
is independent of contention scope, as contention scope merely
defines the set of threads with which a thread must contend
for processor resources, while allocation domain defines the
set of processors for which it contends. The definition of global
contention scope is inconsistent with this, and makes it impossible
for systems with multiple allocation domains to support global conten-
tion scope.
ACTION:
Rewrite lines 186-189 to read: A thread created with global contention
scope contends for resources with all other threads in the same allo-
cation domain relative to their global scheduling attributes. The
global scheduling attributes of a thread created with global conten-
tion scope are the scheduling attributes with which the thread was
created. The global scheduling attributes of a thread created with
local contention scope are the implementation-defined mapping into
global attribute space of the scheduling attributes with which the
thread was created.
--------------------------------------------------------------------------
@ 6.2.2 c 44
44: Section 6.2.2 page 84 line(s) 191
EDITORIAL COMMENT:
Change `which' to `that'.
--------------------------------------------------------------------------
@ 6.2.3 o 45
45: Section 6.2.3 page 84 line(s) 196-219
OBJECTION:
This section implies that both the allocation domain size and the as-
signment of threads to allocation domains is static. Both implica-
tions can be overly restrictive for some systems.
The `process control' approach to scheduling (cf. Tucker and Gupta,
"Process Control and Scheduling Issues for Multiprogrammed Shared
Memory Multiprocessors", Proceedings of 12th SOSP, December 1989, pp.
159-166) obtains significant performance advantages from dynamic allo-
cation domain sizes when it is applicable.
Non Uniform Memory Access (NUMA) multiprocessors (e.g., BBN Butterfly,
Stanford DASH) may use a system scheduling structure that involves
reassignment of threads among allocation domains. In NUMA machines, a
natural model of scheduling is to match allocation domains to clusters
of processors. Load Balancing in such an environment requires chang-
ing the allocation domain to which a thread is assigned. The system
should have the freedom to do this.
ACTION:
After line 208, add: Conforming implementations may change the
size of allocation domains and the binding of threads to allo-
cation domains at any time. Add the second and third para-
graphs of the objection text to the Rationale after line 109.
--------------------------------------------------------------------------
@ 6.3 o 46
46: Section 6.3 page 93 line(s) 481-499
OBJECTION:
The parameter proposed for pthread_yield() is not used and is required
to be NULL. The claim in the rationale that this allows extensions is
bogus. The use of a void * does not permit passing of any integer or
long value, hence does not permit the extensibility that is claimed.
The reference to thread_switch is misplaced in a discussion of a yield
interface; thread_switch is an implementation tool, not a user-level
scheduling tool to skirt around the priority scheduling that the rest
of this chapter says is so important.
ACTION:
Delete the parameter to pthread_yield and lines 490 and 505-510.
--------------------------------------------------------------------------
@ 6.3 o 47
47: Section 6.3 page 95-96 line(s) 551-590
OBJECTION:
The priority ceiling "emulation" protocol is slower that priority in-
heritance in that work must be done in the no-contention case instead
of the contention case. It is also more difficult to use in that the
priority of all calling threads must be computed a priori. It is also
redundant functionality with respect to priority inheritance.
ACTION:
Delete the priority ceiling "emulation" protocol. Delete
pthread_mutexattr_setceiling(), pthread_mutexattr_getceiling(), and
lines 561-587.
--------------------------------------------------------------------------
@ 6.3.4 o 48
48: Section 6.3.4 page 94 line(s) 511-537
OBJECTION:
The specified behavior for threads with global contention scope
directly contradicts the requirements of POSIX.4 for processes with
exactly one thread (namely the initial thread). This is a fundamental
conflict between the scheduling primitives in POSIX.4 and POSIX.4a.
There are two choices here; either resolve the conflict or define it
out of existence.
Resolving the conflict is unlikely to yield a clean solution for
processes that use POSIX.4 scheduling primitives and link against a
library that creates hidden threads. The various choices appear to
be:
a) Treat the initial thread specially and apply POSIX.4 primitives to
it alone.
b) Ensure that a process consisting only of the initial thread is
treated as POSIX.4 scheduling requires
c) Extend POSIX.4 scheduling primitives to all threads.
Option a) is unacceptable because all threads should be as equivalent
as possible, and compatibility support for POSIX.4 primitives is in-
sufficient justification for introducing this degree of asymmetry.
Option c) is also unacceptable because it creates two methods for af-
fecting the scheduling of threads; this both complicates the implemen-
tations and makes the resulting program behavior more difficult to
understand with no benefits. Option b) is the least objectionable of
the three, but leaves a POSIX.4 program at the mercy of
implementation-defined behavior if it should happen to link with a li-
brary that creates internal threads. We offer it as one possible
resolution to this objection with the rationale that an application
performing its own realtime scheduling must understand the scheduling
implications of any library that it links to.
The alternative is to define the problem out of existence by prevent-
ing the simultaneous use of POSIX.4a primitives and POSIX.4 primi-
tives. Doing this at the source level is not straightforward because
of the ability to link separately compiled modules. The linker must
reject any application that attempts to use primitives from both
classes; dynamically linked libraries complicate this problem.
Also, the specified behavior for threads with local contention scope
is an excessively long version of "implementation defined".
ACTION:
Any of the following actions are acceptable to resolve this objection:
(1) Replace lines 522-528 with the following:
The semantics of these functions (except yield()) are exactly as de-
fined in Priority Scheduling s21, POSIX.4 for processes that consist
of an initial thread with global contention scope and have created no
other threads. In all other cases, the semantics are implementation
defined.
(2) Replace lines 522-532 with the following:
The semantics of these functions are implementation defined.
(3) Replace lines 522-532 with the following:
These functions shall fail.
(4) Delete section 6.3.4 (lines 511-537) and replace it with a res-
triction that prevents a conforming implementation from defining both
_POSIX_THREADS and _POSIX_PROCESS_SCHEDULING. Insert a rationale sec-
tion explaining how to do this in practice on a system that can sup-
port each option independently.
--------------------------------------------------------------------------
@ 6.3.4 c 49
49: Section 6.3.4 page 94 line(s) 511-537
EDITORIAL COMMENT:
POSIX.4 has changed the names of the scheduling functions and symbolic
constant used in this section. The new names are prefixed with sched_
and the new symbolic constant is _POSIX_PRIORITY_SCHEDULING.
ACTION:
Update to match POSIX.4.
--------------------------------------------------------------------------
@ 6.3 o 50
50: Section 6.3 page 95-96 line(s) 551-590
OBJECTION:
The priority ceiling "emulation" protocol is slower that priority in-
heritance in that work must be done in the no-contention case instead
of the contention case. It is also more difficult to use in that the
priority of all calling threads must be computed a priori. It is also
redundant functionality with respect to priority inheritance.
ACTION:
Delete the priority ceiling "emulation" protocol. Delete:
pthread_mutexattr_setceiling(),
pthread_mutexattr_getceiling(),
and lines 561-587.
--------------------------------------------------------------------------
@ 7 o 51
51: Section 7 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 7 o 52
52: Section 7 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 7.3 o 53
53: Section 7.3 page 104 line(s) 33-56
OBJECTION:
fork() as defined has only the calling thread continue in the child
process. This introduces problems with locks and other state main-
tained by user code. For example, if the surviving thread in the
child blocks attempting to lock a mutex between fork() and exec(), no
other thread exists to free the lock. This is exacerbated by limited
cancelability (cf. Section 9.3.2, page 126) where a blocking
pthread_mutex_lock operation is not an interruption point, so signals
and other events that might create another thread cannot do so.
There are two useful definitions for fork(), one in which only the
calling thread survives, and a second where all threads in the process
survive in the child. With both alternatives useful under some cir-
cumstances, both should be defined.
ACTION:
Change the name of fork() on this page to "fork1()". Define, under an
option, a new interface, forkall(), defined below, to duplicate all
extant threads in the child process. Specify that it is
implementation-defined whether fork() is fork1() or forkall().
NAME
forkall()
DESCRIPTION
forkall() causes creation of a new process, cloning the parent process
in its entirety including all existing pthreads.
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t forkall(void);
PROCESSING
The new process created by forkall duplicates the calling process, in-
cluding the set of threads that exist as of the time of the call (up to
simultaneity constraints), the data area, and stack(s).
OUTPUT
Upon successful completion, forkall() returns a value of 0 to the new
process and returns the process ID of the new process to the caller.
ERROR/DIAGNOSTICS
On failure, a value of (pid_t) -1 is returned to the caller, no new pro-
cess is created, and errno is set to indicate the error.
EAGAIN
The system limit on number of threads per real user-id would be
exceeded if the call succeeds.
EINTR
A forkall() has been interrupted by a forkall() executed by
another stream of execution in the process.
--------------------------------------------------------------------------
@ 7.3 o 54
54: Section 7.3 page 104 line(s) 33-56
OBJECTION:
In the event that this ballot's objection with action to define for-
kall() is accepted, additional rationale is required to address the
issue of how a portable application would use forkall() and fork1().
--------------------------------------------------------------------------
@ 7.3.1 o 55
55: Section 7.3.1 page 105 line(s)
OBJECTION:
There are at least two serious problems with the semantics of fork()
in a multi-threaded program. One problem has to do with state (e.g.,
memory) covered by mutexes. Consider the case where one thread has a
mutex locked and the state covered by that mutex is inconsistent while
another thread calls fork(). In the child, the mutex will be in the
locked state (locked by a non-existent thread and thus can never be
unlocked). Having the child simply reinitialize the mutex is unsatis-
factory since this approach doesn't resolve the question about how to
correct or otherwise deal with the inconsistent state in the child.
The Pthreads draft suggests that programs that use fork() will call
exec() very soon afterwards in the child process, thus resetting all
state. In the meantime, only a short list of "safe" library routines
are promised to be available.
Unfortunately, this solution does not address the needs of multi-
threaded libraries. Application programs may not be aware that a
multi-threaded library is in use, and will feel free to call any
number of library routines between fork() and exec(), just as they al-
ways have. Indeed, they may be extant single-threaded programs and
cannot, therefore, be expected to obey new restrictions imposed by the
thread library.
On the other hand, the multi-threaded library needs a way to protect
its internal state during fork() in case it is reentered later in the
child process. The problem arises especially in multi-threaded I/O
libraries, which are almost sure to be invoked between fork() and
exec() to effect I/O redirection. The solution may require locking
mutex variables during fork(), or it may entail simply resetting the
state in the child after the fork() processing completes.
pthread_atfork1(), as defined below, provides multi-threaded libraries
with a mechanism to protect themselves from innocent application pro-
grams which call fork(), and it provides multi-threaded application
programs with a standard mechanism for protecting themselves from
fork() calls in a library routine or the application itself.
For example, an application can supply a "prepare" routine that ac-
quires the necessary mutexes the library maintains and "child" and
"parent" routines that release those mutexes, thus ensuring that the
child gets a consistent snapshot of the library's state (and that no
mutexes are left stranded). Alternatively, some libraries might be
able to supply just a "child" routine that reinitializes the library's
mutexes and all associated state to some known value (e.g., what it
was when the image was originally exec'd).
Another problem with the semantics of fork() in a multi-threaded pro-
gram is the question of which threads that exist in the parent are du-
plicated into the child. The Pthreads draft states that the child
process starts with exactly one thread--a copy of the thread that
called fork(). Unfortunately, in some cases, the right thing would
have been to recreate at least some of the other threads in the child
process as well. pthread_atfork1() allows applications and libraries
to deal with this problem as well. A library or application that
creates threads and wants those threads to exist in the child can sup-
ply an pthread_atfork1() "child" routine that recreates the threads.
This is not exactly equivalent to preserving the thread, but it comes
close and should meet most needs.
ACTION:
Add the function pthread_atfork1() as specified below.
NAME
pthread_atfork1() - arrange for fork1 cleanup handling
SYNOPSIS
pthread_atfork1(void (*prepare)(), void (*parent)(), void
(*child)());
void (*prepare)();
void (*parent)();
void (*child)();
DESCRIPTION
pthread_atfork1() declares handlers to be called before and after
fork1(). The prepare handler is called before fork1() processing com-
mences. The parent handler is called after fork1() processing com-
pletes, but in the parent process. The child handler is called after
fork1(0 processing completes, but in the child process.
If no handling is desired at any one of these three places, its
corresponding handler address may be set to NULL.
The expected usage is that the prepare handler acquires all mutex locks,
and the other two handlers release them.
Alternatively, one may also declare only a child handler to just clear
any locks.
The table of fork handlers maintained by pthread_atfork1() should be
semi-static. That is, it is established by calls to pthread_atfork1()
during initialization. Handlers are called in last-in, first-out order,
to enforce any desired locking hierarchy. Therefore, the order of calls
to pthread_atfork1() is significant.
RETURN
pthread_atfork1() returns 0 if successful. Otherwise, it returns -1 if
there is insufficient table space to record the handler addresses.
--------------------------------------------------------------------------
@ 8 o 56
56: Section 8 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 8.3.2 o 57
57: Section 8.3.2 page 111 line(s) 142-143
OBJECTION:
ACTION:
Change these lines to, "POSIX.4a introduces no new async safe func-
tions."
--------------------------------------------------------------------------
@ 8.3.3.4.1.1 o 58
58: Section 8.3.3.4.1.1 page 113 line(s) 207-215
OBJECTION:
The interest model no longer applies with the introduction of the new
signals model.
ACTION:
Delete these lines.
--------------------------------------------------------------------------
@ 8.4.1.1 o 59
59: Section 8.4.1.1 page 115 line(s) 270
OBJECTION:
ACTION:
Change to read "int sigwait(const sigset_t *set);"
--------------------------------------------------------------------------
@ 8.4.1.2 o 60
60: Section 8.4.1.2 page 115 line(s) 276
OBJECTION:
Clarify that it is the caller's responsibility to block signals prior
to a call to sigwait.
ACTION:
Change "defined by set shall be blocked" to "defined by set shall have
been blocked".
--------------------------------------------------------------------------
@ 8.4.1.2 o 61
61: Section 8.4.1.2 page 115 line(s) 274
OBJECTION:
In the presence of an implementation that supports queued signals it
should be guaranteed that sigwait doesn't flush all instances of a
pending signal number.
ACTION:
After the sentence ending "returns that signal number.", add the sen-
tence, "If prior to the call to sigwait there are multiple pending in-
stances of a single signal number, it is implementation-defined wheth-
er upon successful return there are any remaining pending signals for
that signal number."
--------------------------------------------------------------------------
@ 8.4.7.4 o 62
62: Section 8.4.7.4 page 121 line(s) 455
OBJECTION:
ESRCH is a legitimate error return for pthread_kill().
ACTION:
Add it.
--------------------------------------------------------------------------
@ 9 o 63
63: Section 9 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 9 o 64
64: Section 9 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 9.3.5 o 65
65: Section 9.3.5 page 129 line(s) 225-226
OBJECTION:
ACTION:
Change these lines to, "POSIX.4a introduces no new interrupt safe
functions."
--------------------------------------------------------------------------
@ 9.3.4 o 66
66: Section 9.3.4 page 128-129 line(s) 187-217
OBJECTION:
This is rationale.
ACTION:
So indicate.
--------------------------------------------------------------------------
@ 10 o 67
67: Section 10 page all line(s) all
OBJECTION:
The use of ENOSYS as an error return requires that all implementations
maintain stubs simply to return an error. This is silly: the linkage
editor can easily report that a particular function is not available.
ACTION:
Eliminate all [ENOSYS] errors in this Chapter. If the only error is
ENOSYS under a descriptive lead-in paragraph, delete the lead-in para-
graph as well.
--------------------------------------------------------------------------
@ 10 o 68
68: Section 10 page all line(s) all
OBJECTION:
The use of errno is a mistake with new functions. Existing POSIX.1
functions and their close relatives should maintain their overall
structure, as should those tied to existing practice. The use of
errno as a global error indicator in multithreaded environments intro-
duces new difficulties and inefficiencies.
ACTION:
New functions should not set a global errno, but instead return an er-
ror indication as the function return value. The only exception are
functions such as pthread_exit() which do not return, and
pthread_self() which cannot fail. We do not provide synopses for all
such functions, but will on request from the technical reviewers.
Change all new functions such as all pthread_ functions to return an
error indication on failure, as described above.
--------------------------------------------------------------------------
@ 10 c 69
69: Section 10 page all line(s) all
EDITORIAL COMMENT:
This chapter needs reorganization. The ordering of functions and or-
ganization into major subsections is confusing.
ACTION:
Reorder and reorganize the chapter, perhaps as a flat list of func-
tions.
--------------------------------------------------------------------------
@ 10.3.4.2 o 70
70: Section 10.3.4.2 page 155 line(s) 503-504
OBJECTION:
Given that some input functions can implicitly cause output this re-
quirement treated strictly can cause deadlocks. In particular, line
buffered streams will cause the associated output stream to be flushed
upon input.
ACTION:
Add the sentence: "Implicit operations to streams other than the ex-
plicitly referenced stream need not behave as if protected by flock-
file() on such implicitly referenced streams". Also, add rationale
saying that this apparent weakening of the semantics is present to
avoid lock ordering deadlocks. Mention that line buffered streams can
cause this problem.
==============================================================================
--
Robert L. Knighten | knighten@ssd.intel.com
Intel Supercomputer Systems Division |
15201 N.W. Greenbrier Pkwy. | (503) 629-4315
Beaverton, Oregon 97006 | (503) 629-9147 [FAX]
Volume-Number: Volume 27, Number 83
From std-unix-request@uunet.UU.NET Fri Apr 24 19:22:53 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA27742; Fri, 24 Apr 92 19:22:53 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA17649; Fri, 24 Apr 92 19:22:57 -0400
From: Jeffrey Kegler <jeffrey@algor2.algorists.com>
Newsgroups: comp.std.unix
Subject: Hardcopy: I give up
Message-Id: <ta427INNrhu@ftp.UU.NET>
Article-I.D.: ftp.ta427INNrhu
Reply-To: Jeffrey Kegler <jeffrey@algor2.algorists.com>
Organization: Algorists, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 24 Apr 92 23:02:31 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jeffrey@algor2.algorists.com (Jeffrey Kegler)
For those of you who did not read my earlier posting, I laid forth a
pitiful tale of what it involves for an individual to subscribe to the
POSIX documents given the current refusal to provide electronic
access. It costs me about $1000 and two man-weeks a year in collating
the poorly organized loose leafed material. This burden has taken
almost all the resources I can afford to devote to POSIX, and leaves
me without the time to actually comment on the materials.
I have decided when the time comes to replenish my deposit to do so
would be counter-productive. It would only go to perpetuate the
bureaucracy in whose sole interest this bottleneck exists.
Aside from the generation of revenues, the only justification advanced
for the ban on electronic copies is a supposed fear of counterfeits.
I must say "supposed" because there is no evidence of such a concern
in the way the hardcopy is distributed. The materials are
loose-leafed, pages are numbered variously, or unnumbered, often no
clear indication of which page belongs with which materials is
present, and addenda and hand-written corrections on copies are freely
employed. If there is a step that could taken to make a
counterfeiter's life easier that may have been omitted, it slips my
mind.
As many in this audience will know, prevention of counterfeits of
electronic copies is relatively easy. Fresh copies can be obtained
from trusted archives. Checksumming and other more sophisticated
measures are also possible, if needed. The RFC's, for example, have
been available in electronic form for a long time, and this method of
distribution has proved very successful.
Electronic access, in fact, makes it easier to prevent and detect
unauthorized alterations, because the pertinent pieces of the document
can be easily be extracted, mailed, and compared. The argument that
the ban on electronic circulation is based on fear of counterfeiting
fails any examination, and should be seen for the excuse it is. Can
one take even one month's mailing in hardcopy and verify it character
by character? Only in electronic form is this possible.
Let me repeat that the issue is not Jeffrey Kegler's access to draft
standards. This could safely be (in fact, has been) eliminated
entirely with no serious detriment to the process. The issue is a
dangerous narrowing of the audience for review of the standards, at a
point where the review desperately needs to be widened.
--
Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087
Volume-Number: Volume 27, Number 84
From std-unix-request@uunet.UU.NET Tue Apr 28 16:32:43 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19204; Tue, 28 Apr 92 16:32:43 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA09178; Tue, 28 Apr 92 16:32:43 -0400
From: Erik_Brown@transarc.com
Newsgroups: comp.std.unix
Subject: POSIX 1003.4a (Pthread) Comments
Organization: UUNET Communications
Message-Id: <tkcelINNee5@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 Apr 1992 13:27:01 -0700
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: Erik_Brown@transarc.com
Well, this list has been fairly quiet for a little while, so I
thought I'd send my brief comments on the recent threading specs. The
format follows that given in Appendix B of the Draft 6 document.
Please note that I do not speak as a representative of Transarc, but
only on behalf of myself.
Erik Brown eeb@transarc.com
Transarc Corp (412) 338-4426
The Gulf Tower
Pittsburgh, PA 15206
------------------------------------------------------------------
Objections to Draft 6 of the POSIX 1003.4a Specification
------------------------------------------------------------------
Erik Brown (412) 338-4426
eeb@transarc.com FAX: (412) 338-4404
------------------------------------------------------------------
@ 4.4 o 1
PROBLEM
The mutex attributes object may force the pthread_mutex_lock() and
pthread_mutex_unlock() functions to do extra work when a mutex is
acquired or released. The Process-shared attribute especially may
require extra checking for what should be a very low-level and fast
operation.
Providing an interface that allows a very fast low-level locking
mechanism will encourage application developers to write code based
solely on the standard. With the current interface, vendors are
likely to sacrifice portability in the interest of better performance
by attempting to use hardware or OS-specific locking mechanisms where
they are available. This is especially true if an application does
not interact with other processes and all threads run at the same
priority, which is likely to be a common scenerio.
ACTION
The pthread_mutexattr_t structure should be removed from the current
mutex interface.
The mutexattr functionality can be preserved by adding a new type of
locking mechanism with its own attribute object that would allow the
current functionality. The synchronization protocols and priority
ceilings in Section 6.3 would also be folded into this new mechanism.
------------------------------------------------------------------
@ 4.4 c 2
COMMENT
It is unfortunate that pthread_mutex_lock() and
pthread_mutex_unlock() are defined to return a value. On a good RISC
hardware platform with a test-and-set instruction, a lock can be
performed in 2 or 3 instructions in user space, and an unlock in
another 2 or 3 instructions. Forcing these calls to return an integer
value may add another 1 or 2 instruction to the implementation.
In addition, the caller is forced to check the return code of these
calls, adding yet another 4 or 5 instructions (to the lock/unlock
pair). In effect, the cost is almost doubled compared to the same
calls implemented as void functions (assuming no errors).
If users could be "trusted" not to call these routines incorrectly,
or the working group were willing to allow a segmentation fault as the
only error for an incorrectly called pthread_mutex_lock(), then it
would be nice to see both of these calls as void functions.
------------------------------------------------------------------
@ 4.4 o 3
PROBLEM
The definition of pthread_mutex_trylock() induces unnecessary
overhead on the caller. The user must check for -1, and then check
for EBUSY to ensure that -1 was returned because the lock was already
held.
ACTION
Change the definition of this routine to return a boolean value, or
-1 if a real error occurs. That is, change lines 330 to 332 as
follows:
The function pthread_mutex_trylock() returns a positive
integer if the lock on the mutex object referenced by mutex is
acquired. It returns 0 if the mutex is already locked. If an
error occurs, it returns -1 and sets errno to indicate the
error.
------------------------------------------------------------------
@ 5.2 o 4
PROBLEM
The pthread_getspecific() function in 5.2.2.1 is essentially a
mechanism for providing special thread-specific memory. This is
likely to be heavily used by threaded applications, so performance of
this function will be critical. The performance of the current
function is not optimal because the user must examine both the return
code from the function and the value returned in the value parameter.
ACTION
Change the routine to return the value of the given key, rather than
accepting an address to store the value into. If the key is invalid,
0 would be returned. For instance, line 148 would change to be
void *pthread_getspecific(pthread_key_t key);
------------------------------------------------------------------
@ 6.3 o 5
PROBLEM
The mutex attributes object may force the pthread_mutex_lock() and
pthread_mutex_unlock() functions to do extra work when a mutex is
acquired or released. Putting scheduling logic into the low-level
synchronization primitive may be overkill for applications that run
all of its threads with the same priority, or with mutexes that do not
cross thread priority boundaries.
Providing an interface that allows a very fast low-level locking
mechanism will encourage application developers to write code based
solely on the standard. With the current interface, vendors are
likely to sacrifice portability in the interest of better performance
by attempting to use hardware or OS-specific locking mechanisms where
they are available. This is especially true if an application does
not interact with other processes and all threads run at the same
priority, which is likely to be a common scenerio.
ACTION
While not applying to this section, the pthread_mutexattr_t
structure should be removed from the interface. A new type of locking
mechanism can provide the synchronization protocols and priority
ceilings in its own attribute object. These functions should then be
described in terms of this new interface.
------------------------------------------------------------------
@ 8.3 o 6
PROBLEM
The list of async safe functions in 8.3.2 seems to be incomplete.
In particular, the functions pthread_mutex_unlock() and pthread_self()
should also be asyn safe.
ACTION
Add these functions to the list given in the final paragraph.
------------------------------------------------------------------
@ 8.4 o 7
PROBLEM
It seems reasonable that more than one thread in the same process
might be interested in the same signal via the sigwait() function.
Section 8.4.1.2 states that "exactly one of these threads shall return
from sigwait() with the signal number."
This seems unduly harsh. For example, various libraries may wish to
clean up from the receipt of a SIGINT, or check for a created child
process (with a polling call to waitpid) when SIGCHLD is received.
Allowing multiple libraries to perform these actions seems worthwhile
ACTION
Change the second paragraph in Section 8.4.1.2 to read
If more than one thread is using sigwait() to wait for the
same signal then all of these threads shall return from
sigwait() with the signal number. No order can be assumed in
the delivery of the signals to the waiting threads. Also, if
a thread exits the program after a return from sigwait(), then
other threads that were also waiting for the signal may not
actually receive it.
------------------------------------------------------------------
Volume-Number: Volume 27, Number 85
From std-unix-request@uunet.UU.NET Fri May 1 21:51:23 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA08111; Fri, 1 May 92 21:51:23 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA11689; Fri, 1 May 92 21:51:22 -0400
From: Ron Christian <uswnvg!rchrist@uunet.UU.NET>
Newsgroups: comp.std.unix
Subject: Are bugfixes proprietary?
Message-Id: <tsqu8INNpfe@ftp.UU.NET>
Organization: US West NewVector, Bellevue, WA
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 May 92 01:23:20 GMT
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: rchrist@uswnvg.UUCP (Ron Christian)
Recently, in the process of getting a nasty bug fixed, I asked a
computer vendor if this bug fix would be communicated back to the Unix
standards organization from which they got their bits, since the bug
was in the original code. (Both computer vendor and standards
organization will remain nameless for now.) The vendor's response was
"there is currently no mechanism to communicate bug reports back to
<organization>". This sounded interesting, so I asked a couple other
vendors if they reported bugs or bugfixes. I got one "yes" response
and one other "currently no mechanism" response.
Now, this is not by any means a significant sampling of computer
vendors, but it leads me to ask the question in this forum. Are
vendors who produce an ostensibly standards-based Unix expected to
report bugs back to the standards organization, or is it the general
expectation of the industry that bug fixes are value added by the
vendor and hence proprietary? Or, is there simply too much overhead
involved in reporting bugs in some reasonably structured fashion? If
vendors typically don't report bugs, how are standards organizations
(USL, OSF, Posix, X/Open, etc) made aware of them?
I guess I'm interested in how the system is supposed to work, and also
people's observations on how the system works (or doesn't work) in real
life.
Thanks in advance.
Ron
Volume-Number: Volume 27, Number 86
From std-unix-request@uunet.UU.NET Mon May 4 18:01:55 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17992; Mon, 4 May 92 18:01:55 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA02536; Mon, 4 May 92 18:01:52 -0400
From: Matthew Wicks <wicks@dcdmjw.fnal.gov>
Newsgroups: comp.std.unix
Subject: Re: Are bugfixes proprietary?
Message-Id: <u49s6INNoej@ftp.UU.NET>
Article-I.D.: ftp.u49s6INNoej
References: <tsqu8INNpfe@ftp.UU.NET> <tsqu8INNpfe@ftp.UU.NET>,
Organization: Fermi National Accelerator Laboratory, Batavia IL
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 4 May 92 21:21:10 GMT
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: wicks@dcdmjw.fnal.gov (Matthew Wicks)
In article <tsqu8INNpfe@ftp.UU.NET>, rchrist@uswnvg.UUCP (Ron Christian) writes:
>Are
>vendors who produce an ostensibly standards-based Unix expected to
>report bugs back to the standards organization, or is it the general
>expectation of the industry that bug fixes are value added by the
>vendor and hence proprietary? Or, is there simply too much overhead
>involved in reporting bugs in some reasonably structured fashion? If
>vendors typically don't report bugs, how are standards organizations
>(USL, OSF, Posix, X/Open, etc) made aware of them?
It is necessary to differentiate between organizations such as IEEE (POSIX)
and USL or OSF. In the first case, POSIX is just a specification, thus
can't contain a bug of the manner you describe. Now of course the standard
could be poorly specified and thus need changing, but there are official
procedures for that.
On the other hand, USL and OSF license and distribute code and thus should
have some mechanism to allow their customers to report bugs.
--
Matt Wicks
Fermi National Accelerator Laboratory
wicks@fnal.fnal.gov
708-840-8083
[ Also noted by gisle@ifi.uio.no, gwyn@moke.brl.mil, duke@cupid.UUCP -- mod ]
Volume-Number: Volume 27, Number 87
From std-unix-request@uunet.UU.NET Wed May 6 15:14:44 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10471; Wed, 6 May 92 15:14:44 -0400
Received: from kithrup.COM by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15208; Wed, 6 May 92 15:14:41 -0400
From: "Shane P. McCarron" <ahby@ui.org>
Newsgroups: comp.std.unix
Subject: Debugging Information Format specification available for review
Keywords: DWARF debug
Message-Id: <u99vaINN5k5@ftp.UU.NET>
Article-I.D.: ftp.u99vaINN5k5
Organization: UNIX International
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 May 92 18:53:30 GMT
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: ahby@ui.org (Shane P. McCarron)
The UNIX International Programming Languages Special Interest Group
has completed a draft of the DWARF debugger format specification, and
is making it available for industry review. As with all UNIX
International developed specifications, this document is available
for distribution without restriction under an X Window System-like
copyright.
Attached below is the Foreword and Introduction from the document. If
you would like to receive a copy, send mail to archive@ui.org
containing the following:
path yourname@your.site
send PUBLIC/dwarf.v1.mm
for the troff source, or
send PUBLIC/dwarf.v1.ps
for the postscript. If you system supports uncompress and uudecode, you
can request that the data be compressed by placing the command 'compress'
in the message.
If you have any questions about the archive service, please contact
me. If you have questions about the Programming Languages SIG or the
DWARF specification, please contact the SIG chair, Dan Oldman, at
d.oldman@ui.org. If you are interested in participating in the
ongoing discussions of the Programming Languages SIG, please send a
message containing your fully qualified internet address to
plsig-request@ui.org.
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
DWARF Debugging Information Format
FOREWORD
This document specifies a new generation of symbolic
debugging information that has been developed by the UNIX
International Programming Languages Special Interest Group
(SIG), and is being circulated for industry review. We
started from the document DWARF Debugging Information
Requirements - Issue 2, dated April 4, 1990, made available
by AT&T to its source licensees, and added a significant
amount of material to clarify what was originally specified
and to support additional language constructs that were not
in the original specification.
At this point, the SIG believes that this document
sufficiently supports the debugging needs of C, C++, and
FORTRAN 77, and we have released it for public comment. We
will accept comments on this document until June 15, 1992.
Comments may be directed via email to me or posted to the
SIG mailing list (plsig@ui.org). If you are unable to send
email, paper mail, FAX, or machine readable copy on UNIX,
MS-DOS, or Macintosh compatible media can be sent to me, and
I will post it for you.
Tony D'Annunzio
Vice President of Technology
UNIX International
Waterview Corporate Center
20 Waterview Boulevard
Parsippany, NJ 07054
Phone: +1 201-263-8400
Fax: +1 201-263-8401
Revision: 1.0.0 Page 1 January 20, 1992
Industry Review Draft
Programming Languages SIG
1. INTRODUCTION
This document defines the format for the information
generated by compilers, assemblers and linkage editors that
is necessary for symbolic, source-level debugging. The
debugging information format does not favor the design of
any compiler or debugger. Instead, the goal is to create a
method of communicating an accurate picture of the source
program to any debugger in a form that is economically
extensible to different languages while retaining backward
compatibility.
The design of the debugging information format is open-
ended, allowing for the addition of new debugging
information to accommodate new languages or debugger
capabilities while remaining compatible with other languages
or different debuggers.
1.1 Purpose and Scope
The debugging information format described in this document
is designed to meet the symbolic, source-level debugging
needs of different languages in a unified fashion by
requiring language independent debugging information
whenever possible. Individual needs, such as C++ virtual
functions or Fortran common blocks are accommodated by
creating attributes that are used only for those languages.
This document describes DWARF Version 1, which is designed
to be binary compatible with the debugging information that
is described in the document DWARF Debugging Information
Requirements - Issue 2, dated April 4, 1990, and made
available by AT&T to its source licencess. The April 4,
1990, document describes the debugging information that is
generated by the UNIX System V Release 4 C compiler and
consumed by the System V Release 4 debugger, sdb.
By ``binary compatibility'' we mean that
1. All features intended to support C and Fortran
described in the April 4, 1990, document are included
in this document, and
2. DWARF produced according to this (DWARF Version 1)
specification should be considered well formed by a
System V Release 4 compatible DWARF consumer, but may
contain information that such a consumer is unable to
interpret. Consumers are expected to ignore such
information.
Revision: 1.0.0 Page 3 January 20, 1992
Industry Review Draft
DWARF Debugging Information Format
The intended audience for this document are the developers
of both producers and consumers of debugging information,
typically language compilers, debuggers and other tools that
need to interpret a binary program in terms of its original
source.
This version of the document is a draft for industry review.
Vendors developing products based on this draft should be
aware that the review process may produce changes.
1.2 Overview
There are two major pieces to the description of the DWARF
format in this document. The first piece is the debugging
information, itself. Section two describes the overall
structure of that information. Section three describes the
specific debugging information entries and how they
communicate the necessary information about the source
program to a debugger.
The second piece of the DWARF description is the way the
debugging information is encoded and represented in an
object file. The DWARF encoding is presented in section
four.
Section five describes compatibility constraints on the
format. Finally, section six describes external
dependencies.
In the following sections, text in normal font describes
required aspects of the DWARF format. Text in italics is
explanatory or supplementary material, and not part of the
format definition itself.
1.3 Vendor Extensibility
This document describes only the features of DWARF that have
been implemented and tested by at least one vendor (with a
very few exceptions). It does not attempt to cover all
languages or even to cover all of the interesting debugging
information needs for its primary target languages (C, C++,
Fortran). Therefore the document provides vendors a way to
define their own debugging information tags, attributes,
fundamental types, type modifiers, location atoms and
language names, by reserving a portion of the name space and
valid values for these constructs for vendor specific
additions. Future versions of this document will not use
names or values reserved for vendor specific additions. All
names and values not reserved for vendor additions, however,
are reserved for future versions of this document. See
section 4 for details.
Revision: 1.0.0 Page 4 January 20, 1992
Industry Review Draft
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
[ I wasn't sure about allowing this here. Please let me know whether
or not you, the readers, want information like this posted -- mod ]
Volume-Number: Volume 27, Number 88
From std-unix-request@uunet.UU.NET Fri May 8 14:15:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA11018; Fri, 8 May 92 14:15:12 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21489; Fri, 8 May 92 14:15:16 -0400
From: Bob Robillard <duke@ctt.bellcore.com>
Newsgroups: comp.std.unix
Subject: POSIX 1003.1/1003.16 (Language Independent POSIX Ballot extended)
Organization: UUNET Communications
Message-Id: <ued6sINNi5l@ftp.UU.NET>
Reply-To: duke@ctt.bellcore.com
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 8 May 1992 10:19:24 -0700
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: duke@ctt.bellcore.com (Bob Robillard)
The deadline for getting in the ballot group for POSIX
1003.1/1003.16 has been extended to May 15. This is the
"Language Independent" version and "C binding" of the
POSIX system calls. If you care about the way that all
future POSIX APIs will be written I suggest you ballot
this draft.
The sign-up form IEE sent out says to contact IEEE's Anna
Kaczmarek at 908-562-1571 to get involved with this.
(Don't get in touch with me; I'm just a civilian about
this...)
For people unfamiliar with POSIX's new "Language Independent"
movement, here's my heavily biased take: Bew POSIX APIs
will not be C language APIs. They have to be written in
new, invented programming language that is supposed to be
easily translatable to Ada, or Fortran, or even C. API's
written in this new, invented programming language are called
"Language Independent APIs."
Each "Language Independent APIs" should come with translations
to real programming languages (like C, Ada and Fortran). These
translations are called "bindings." In order to find out what
a given function is supposed to do, you'll need to read the
Language Independent Spec to find out the basic functionality,
and then read the language binding to find out the syntax and
language specific functionality.
Bob Robillard, Technical Editor, 1003.7 Bellcore
duke@cc.bellcore.com RRC 1D-229
bcr!cupid!duke 444 Hoes Lane
908-699-2249, FAX: 908-336-2827 Piscataway, NJ 08854
Volume-Number: Volume 27, Number 89
From std-unix-request@uunet.UU.NET Fri May 8 22:27:27 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04446; Fri, 8 May 92 22:27:27 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA05278; Fri, 8 May 92 22:27:34 -0400
From: James Buster <bitbug@netcom.com>
Newsgroups: comp.std.unix
Subject: Posix.1 oddity: why specify this?
Message-Id: <ufb93INNq8m@ftp.UU.NET>
Organization: Lynx Real-Time Systems, Inc.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 May 92 01:52:35 GMT
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: bitbug@netcom.com (James Buster)
Moderator!: Delete most of these lines (begin):
In IEEE Posix Std. 1003.1 (ISO/IEC 9945-1) states, under the definition
of utime() (Pages 108-110):
"If the _times_ argument is not NULL, it is interpreted as a
pointer to a utimbuf structure, and the access and modification
times are set to the values contained in the designated structure.
Only the owner of the file and processes with appropriate
privileges shall be permitted to use the utime() function in
this way."
Later, in the Errors section:
[EPERM] The _times_ argument is not NULL, the effective user ID of the
calling process has write access to the file, but does not
match the owner of the file, and the calling process does not
have the appropriate privileges.
Here is my question: Why mention write access in the EPERM description?
Clearly, as described above, if _times_ isn't NULL, write access is not
considered when determining whether to grant a successful call to utime().
I can only conclude that mentioning write access is an error on the part
of the drafters of this document. Any Posix experts care to comment?
--
James Buster
bitbug@netcom.com
Volume-Number: Volume 27, Number 90
From std-unix-request@uunet.UU.NET Wed May 13 15:45:59 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04688; Wed, 13 May 92 15:45:59 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07219; Wed, 13 May 92 15:46:02 -0400
From: Brian Button <bab@se39.wg2.waii.com>
Newsgroups: comp.std.unix
Subject: POSIX binary semaphore question
Organization: Western Geophysical Exploration Products
Message-Id: <urr82INNan5@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 May 1992 12:38:42 -0700
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: bab@se39.wg2.waii.com (Brian Button)
Is there a way to find out the control information regarding POSIX.4
binary semaphores? I need a way to find out the uid and gid of the
creator and the size of the semaphore set which was created.
Any suggestions?
--
Brian Button | email : button@wg2.waii.com, bab@buster.stafford.tx.us
Design Engineer | voice : (713)964-6221
Western Geophysical
3600 Briarpark
Houston, Texas 77042
Volume-Number: Volume 27, Number 93
From std-unix-request@uunet.UU.NET Wed May 13 15:48:29 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04825; Wed, 13 May 92 15:48:29 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07902; Wed, 13 May 92 15:48:33 -0400
From: Ian Lance Taylor <ian@airs.com>
Newsgroups: comp.std.unix
Subject: UUCP standardization effort
Message-Id: <urqs9INNagg@ftp.UU.NET>
Article-I.D.: ftp.urqs9INNagg
Organization: UUNET Communications
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 May 92 19:32:25 GMT
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: ian@airs.com (Ian Lance Taylor)
I recently discovered that the UUCP program suite is apparently being
considered for standardization by the POSIX networking interfaces
group. Is the group actively meeting, and, if so, is there any way to
get in touch with the relevant people via e-mail?
Thanks, and apologies if this is well-known information.
--
Ian Lance Taylor ian@airs.com uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``They were all-but forgotten people: the breed that was remembered with a
start, or with the unreality of a recrudescent dream.''
Volume-Number: Volume 27, Number 91
From std-unix-request@uunet.UU.NET Wed May 13 15:48:37 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04833; Wed, 13 May 92 15:48:37 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07927; Wed, 13 May 92 15:48:41 -0400
From: ritley@uimrl7.mrl.uiuc.edu
Newsgroups: comp.std.unix
Subject: Anyone heard of PICK???
Message-Id: <urqvbINNaif@ftp.UU.NET>
Reply-To: ritley@uiucmrl.bitnet
Organization: Materials Research Lab
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 May 92 19:34:03 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ritley@uimrl7.mrl.uiuc.edu
I have heard of something called PICK, which, from what little I've heard,
seems to be some sort of user-friendly, business-application-oriented
shell which runs on top of Unix.
It sounds like this is something standard.
I know there are books about PICK, but can anyone provide me with some
on-line sources of information, etc. --- such as anonymous-ftp
sites for PICK utilities and so forth?
Many thanks!
Volume-Number: Volume 27, Number 92
From std-unix-request@uunet.UU.NET Thu May 14 14:51:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16090; Thu, 14 May 92 14:51:50 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19742; Thu, 14 May 92 14:51:54 -0400
From: Malcolm Stayner <malcolm@usenet.icl.co.nz>
Newsgroups: comp.std.unix
Subject: COMMA SEPARATED VALUE FILES
Organization: Office Support Centre, Fujitsu ICL (NZ) Ltd, Wellington, New Zealand
Message-Id: <uuc7dINN31a@ftp.UU.NET>
Reply-To: Malcolm Stayner <usenet!malcolm@uunet.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: CSV,standards
X-Submissions: std-unix@uunet.uu.net
Date: 14 May 1992 11:40:45 -0700
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: malcolm@usenet.icl.co.nz (Malcolm Stayner)
I've recently come across a situation where a UNIX application incorrectly
processed a CSV file because null fields were not delimited by double quotes.
e.g.
Apple,Banana,,,Orange
instead of:
Apple,Banana,"","",Orange
Does anyone know of a formal standard for CSV files and, in particular the
correct rules for the above situation?
--
Malcolm Stayner Email: malcolm@icl.co.nz "Intelligence is silence,
Open Systems Consultant Tel: +64-4-472 4884 truth is being invisible,
Fujitsu ICL N.Z. Ltd Fax: +64-4-472 6737 but what a racket I make in
P.O. Box 394, Wellington, New Zealand declaring this" NED ROREM
Volume-Number: Volume 27, Number 94
From std-unix-request@uunet.UU.NET Thu May 14 16:47:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA23998; Thu, 14 May 92 16:47:47 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19953; Thu, 14 May 92 16:47:52 -0400
From: Chris Wagner <jwag@moose.asd.sgi.com>
Newsgroups: comp.std.unix
Subject: Feature Test macros for POSIX
Organization: Silicon Graphics, Research & Development
Message-Id: <uugn6INN4k6@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 14 May 1992 12:57:26 -0700
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: jwag@moose.asd.sgi.com (Chris Wagner)
I am trying to figure out the feature test macro for POSIX1003.4 and 4a.
Although draft 12 gives lots of compile-time option constants, it seems
to imply that the only feature test macro is _POSIX_C_SOURCE.
Draft12 seems to imply that as of a certain date (the date of approval
I assume) all the symbols defined in POSIX1003.4 will suddenly be
added to header files such as stdio.h, etc. A user can optionally
set _POSIX_C_SOURCE to an earlier date to preclude certain symbols.
Is this right?? It seems kind of silly to base visibility on date.
I would expect that most developers will still want to be able
to demand a pure 1003.1 symbol environment.
Is this _POSIX_C_SOURCE just a 1003.4 hack? or has it been
formally adopted at the way the future POSIX stds will
be added to existing headers.
It seems to me that each standard should add feature test macros that
can be defined at compile time...(e.g. _POSIX_4SOURCE, etc.)
----
Chris Wagner (jwag@sgi.com)
Volume-Number: Volume 27, Number 95
From std-unix-request@uunet.UU.NET Sat May 16 21:03:38 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00650; Sat, 16 May 92 21:03:38 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18974; Sat, 16 May 92 21:03:44 -0400
From: David A Willcox <willcox@urbana.mcd.mot.com>
Newsgroups: comp.std.unix
Subject: Re: Feature Test macros for POSIX
Message-Id: <v139nINNr4n@ftp.UU.NET>
References: <uugn6INN4k6@ftp.UU.NET>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 May 92 19:26:47 GMT
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: willcox@urbana.mcd.mot.com (David A Willcox)
jwag@moose.asd.sgi.com (Chris Wagner) writes:
>I am trying to figure out the feature test macro for POSIX1003.4 and 4a.
>Although draft 12 gives lots of compile-time option constants, it seems
>to imply that the only feature test macro is _POSIX_C_SOURCE.
>Draft12 seems to imply that as of a certain date (the date of approval
>I assume) all the symbols defined in POSIX1003.4 will suddenly be
>added to header files such as stdio.h, etc. A user can optionally
>set _POSIX_C_SOURCE to an earlier date to preclude certain symbols.
>Is this right?? It seems kind of silly to base visibility on date.
>I would expect that most developers will still want to be able
>to demand a pure 1003.1 symbol environment.
>Is this _POSIX_C_SOURCE just a 1003.4 hack? or has it been
>formally adopted at the way the future POSIX stds will
>be added to existing headers.
A short tutorial on POSIX feature test macros ...
OK, here's the the way it works. An ANSI C compiler is not allowed to
make symbols visible to an application beyond what's defined in ANSI
C, unless the application does something explicit to make those
symbols available. The application does this by defining one or more
feature test macros before including any headers. Basically, if the
application defines a feature test macro, it is saying that it "knows"
about, and is willing to deal with, the additions to the name space
that are associated with that feature test macro.
_POSIX_C_SOURCE is the new POSIX method for controling visibility of
POSIX symbols. The application sets _POSIX_C_SOURCE to a date value,
and that PERMITS the implementation to make visible any symbols
associated with parts of POSIX that were approved on or before that
date. (Using a date as the value is arbitrary. A simple integer that
was incremented with each new revision could have been used, but we
felt that a date would be more meaningful to humans.) The
implementation then informs the application which options it actually
supports through version macros (e.g. _POSIX_VERSION and
_POSIX2_C_VERSION), or specific "feature present" macros (e.g.
_POSIX_SYNCHRONIZED_IO).
So, if an application only wants to see only POSIX.1 ("POSIX Classic"),
then it will define _POSIX_SOURCE. Only symbols defined in IEEE
Std 1003.1-1990 (or -1988) will appear, even if the implementation
supports POSIX.2, POSIX.4, and ten other options that haven't been
created, yet. An application that needs POSIX.1 and POSIX.2 Annex B
will define _POSIX_C_SOURCE to 199208L [exact value not yet
determined], and POSIX.4 symbols will not appear. An application that
wants only POSIX.4 will define _POSIX_C_SOURCE to 199209L [again,
exact value not yet determined], and the implementation is then
permitted to make visible symbols from POSIX.1, POSIX.2, and POSIX.4.
A couple of things to note:
(1) Just because the application sets _POSIX_C_SOURCE to a value, does
not mean that the imlementation supports all of the requested
options. If the application sets _POSIX_C_SOURCE to 199209L
[using the above example] but the implementation doesn't support
POSIX.4, then clearly POSIX.4 symbols might or might not appear.
(2) There is no way for an application to say "I want POSIX.4 symbols
but NOT POSIX.1 or POSIX.2 symbols. It doesn't need to use the
unwanted options, but it must respect the reserved namespace of all
options defined before
(3) It is our hope that the IEEE will publish a table saying "here are
the symbols defined if <header.h> is included and _POSIX_C_SOURCE
is set to yyyymmL" whenever a new revision is approved.
(4) If this was all consistent, defining _POSIX_C_SOURCE as 199009L
would be equivalent to defining _POSIX_SOURCE. Unfortunately,
that isn't required by the current version of POSIX.1.
>It seems to me that each standard should add feature test macros that
>can be defined at compile time...(e.g. _POSIX_4SOURCE, etc.)
The feature test macros are defined at compile time, it's just that
there is only one feature test macro instead of many.
Something that many people don't understand is that the different
POSIX.* docuements are not different standards. POSIX.2 Annex B,
POSIX.4, POSIX.4a, POSIX.1a, plus several others, are revisions of
POSIX.1 describing optional features. Ultimately, they are all
considered part of one ISO standard, 9945-1. (Somebody will probably
correct me on this, but 9945-2 is shell and utilities [most of POSIX.2],
and 9945-3 is system administration.) So it actually makes more sense
for all of the C bindings to use the same feature test macro than to
give each option of the standard its own feature test macro.
David A. Willcox "Just say 'NO' to universal drug testing"
Motorola MCG - Urbana UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave. INET: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 27, Number 96
From std-unix-request@uunet.UU.NET Sat May 16 21:03:44 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00657; Sat, 16 May 92 21:03:44 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA18985; Sat, 16 May 92 21:03:51 -0400
From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: comp.std.unix
Subject: Re: Anyone heard of PICK???
Organization: U of Toronto Zoology
Message-Id: <v13ajINNr6d@ftp.UU.NET>
References: <urqvbINNaif@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 May 1992 12:27:15 -0700
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)
>Submitted-by: ritley@uimrl7.mrl.uiuc.edu
>I know there are books about PICK, but can anyone provide me with some
>on-line sources of information, etc. --- such as anonymous-ftp
>sites for PICK utilities and so forth?
Unless things have changed since I last encountered it, PICK is a proprietary
product of one particular company, and you will have to talk to them about
machine-readable documentation, utilities, etc.
It used to be a complete operating system, in fact. They eventually saw
which way the wind was blowing and did a port to the Unix environment.
--
ISDN, n: Incredibly Slow and Dumb | Henry Spencer @ U of Toronto Zoology
Networking | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 27, Number 97
From std-unix-request@uunet.UU.NET Mon May 18 23:06:48 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16231; Mon, 18 May 92 23:06:48 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26475; Mon, 18 May 92 23:06:53 -0400
From: Bob Larson <blarson@mizar.usc.edu>
Newsgroups: comp.std.unix
Subject: Re: Anyone heard of PICK???
Organization: USC Software Systems, home of TOADS
Message-Id: <v8vecINNn3a@ftp.UU.NET>
References: <urqvbINNaif@ftp.UU.NET> <v13ajINNr6d@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 18 May 1992 12:10:04 -0700
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: blarson%mizar.usc.edu@usc.edu (Bob Larson)
Pick is a data-base and operating enviornment (including programming
language) designed around the commands used to query the data-base.
It's main strength is the ability to quickly design new reports.
In article <v13ajINNr6d@ftp.UU.NET> henry@zoo.toronto.edu (Henry Spencer) writes:
>>Submitted-by: ritley@uimrl7.mrl.uiuc.edu
>>I know there are books about PICK, but can anyone provide me with some
>>on-line sources of information, etc. --- such as anonymous-ftp
>>sites for PICK utilities and so forth?
>
>Unless things have changed since I last encountered it, PICK is a proprietary
>product of one particular company,
Technicly true, although that is also true of Unix. However, the
(proprietary to other companies) work-betters have been around for
well over a decade. (Unlike Unix, where no-AT&T code work-alikes are
relitivly recent.) There are at least four competing variations
running on various Unix platforms, (Universe, Unidata, Prime
Information/Open, and Advanced Pick) as well as those running on other
operating systems and stand alone.
>and you will have to talk to them about
>machine-readable documentation, utilities, etc.
There are several magizines devoted to Pick-Alikes, and various
user-groups and trade shows. Quite a few companies make their living
selling utilities and doing consulting on Pick systems.
I don't know of any FTP sites. Comp.sys.prime sometimes has
discussions of Prime Information and Prime Information/Open.
>It used to be a complete operating system, in fact.
And still is. Although cheap Unix boxes are making it less common.
>They eventually saw
>which way the wind was blowing and did a port to the Unix environment.
After noting lost sales to compeditors.
Disclaimer: I work for a company that sells a utility for building
data entry screens for three of the four above mentioned Pick-based
eviornments, and sells one of them. (And even Unix boxes to run it
on, if you want.) Call +1(213)743-0091 and ask for someone in sales
if you are interested.
Volume-Number: Volume 27, Number 98
From std-unix-request@uunet.UU.NET Mon May 18 23:06:56 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16237; Mon, 18 May 92 23:06:56 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26498; Mon, 18 May 92 23:07:03 -0400
From: Al Bledsoe <abledsoe@sdf.lonestar.org>
Newsgroups: comp.std.unix
Subject: Re: Anyone heard of PICK???
Organization: sdf Public Access UNIX, Dallas--unrestricted free shell access
Message-Id: <v8vf6INNn4l@ftp.UU.NET>
References: <urqvbINNaif@ftp.UU.NET> <v13ajINNr6d@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 18 May 1992 12:10:30 -0700
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: abledsoe@sdf.lonestar.org (Al Bledsoe)
>>I know there are books about PICK, but can anyone provide me with some
>>on-line sources of information, etc. --- such as anonymous-ftp
>
>It used to be a complete operating system, in fact. They eventually saw
PICK has been ported to UNIX for awhile now. UniVerse by Vmark and
Unidata are serious implementations. It is a DBMS that is relational
but not Codd relational. Read BYTE of May 1992, "Two Steps Forward
and One Step Back". PICK is similar to MUMPS in that it has existed in
vertical niche markets. But even though PICK is not ANSI like MUMPS
the InfoBASIC language and file structure make it quite a serious
contender in real world development cycles. Unidata provides a SQL
frontend and UniVerse's release 7 will have SQL. I'm from a MUMPS
background doing migration from PICK to Informix. The transactional
section of the package will be left in PICK and the analytical in
Informix Wingz.
PICK and MUMPS kick RDBMS's to pieces in performance, with SQL their
once closed nature will be open, shoot, running on most open
systems now, without SQL maybe they're open already... read the BYTE
article.
---
abledsoe@sdf.lonestar.org
Volume-Number: Volume 27, Number 99
From std-unix-request@uunet.UU.NET Mon May 18 23:07:02 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16245; Mon, 18 May 92 23:07:02 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26536; Mon, 18 May 92 23:07:09 -0400
From: David A Willcox <willcox@urbana.mcd.mot.com>
Newsgroups: comp.std.unix
Subject: Re: Feature Test macros for POSIX
Message-Id: <v8vg1INNn64@ftp.UU.NET>
Article-I.D.: ftp.v8vg1INNn64
References: <uugn6INN4k6@ftp.UU.NET> <v139nINNr4n@ftp.UU.NET>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 18 May 92 19:10:57 GMT
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: willcox@urbana.mcd.mot.com (David A Willcox)
willcox@urbana.mcd.mot.com (David A Willcox) writes:
Just to keep the record straight...
> ... POSIX.2 Annex B,
>POSIX.4, POSIX.4a, POSIX.1a, plus several others, are revisions of
>POSIX.1 describing optional features. Ultimately, they are all
>considered part of one ISO standard, 9945-1. ...
POSIX.2, Annex B, though it does contain C functions, is not currently
part of 9945-1, but rather 9945-2. However, there is a proposal on
the floor to move that part of POSIX.2 into POSIX.1 and POSIX.16.
(The C interfaces would go into POSIX.16. The not-yet-written
language-independent versions would go into POSIX.1.) As I understand
it (don't take my word for this), those C functions would then become
part of 9945-1.
Volume-Number: Volume 27, Number 100
From std-unix-request@uunet.UU.NET Mon May 18 23:07:08 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16252; Mon, 18 May 92 23:07:08 -0400
Received: from kithrup.COM by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26550; Mon, 18 May 92 23:07:16 -0400
From: Doug Gwyn <gwyn@smoke.brl.mil>
Newsgroups: comp.std.unix
Subject: Re: Feature Test macros for POSIX
Message-Id: <v8vhlINNn7h@ftp.UU.NET>
Article-I.D.: ftp.v8vhlINNn7h
References: <uugn6INN4k6@ftp.UU.NET> <v139nINNr4n@ftp.UU.NET>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 18 May 92 19:11:49 GMT
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: gwyn@smoke.brl.mil (Doug Gwyn)
In article <v139nINNr4n@ftp.UU.NET> willcox@urbana.mcd.mot.com (David A Willcox) writes:
>OK, here's the the way it works. An ANSI C compiler is not allowed to
>make symbols visible to an application beyond what's defined in ANSI
>C, unless the application does something explicit to make those
>symbols available. The application does this by defining one or more
>feature test macros before including any headers.
More accurately: In order to conform to the C standard, a C implementation
must, among other requirements, accept any strictly conforming C program.
A strictly conforming C program must, among other requirements, not use
certain classes of identifiers in contexts where they have been reserved
for use by C implementations. And a conforming C implementation must not
define any identifiers in the standard headers other than those specified
in the standard plus those reserved for implementations. (Reserved
identifiers mostly begin with underscore; see the C standard for details.)
There are no requirements on any headers other than those specified in the
standard; thus additional facilities can AND SHOULD be defined by separate
headers, not through modifications to the standard headers. This is
especially important when the standard C implementation is provided by
one source of supply but the additional functionality is provided by a
different source of supply, as frequently ocurs in this industry.
The only reason there was any need for "feature flags" in the first place
was the historical accident that some of the standard headers (notably
<stdio.h>) included interface definitions for UNIX-specific facilities AND
general portably-available facilities. The C standard does not single out
the UNIX environment for an exception, but rather prohibits pollution of
the identifier name spaces by ANY conforming implementation. Thus, for
<stdio.h> and a few other standard headers, a conforming C implementation
can make additional non-reserved symbols (such as "popen") visible ONLY to
programs that are NOT strictly conforming. The method chosen by 1003.1 for
this was for the program to somehow #define _POSIX_SOURCE before including
the relevant standard header. This allows the implementation to key on
that symbol to "turn on" additional symbols in the standard header, without
those symbols being visible in the absence of such a feature flag.
As the last acting liaison between X3J11 and P1003, I was heavily involved
in getting this issue resolved. 1003.1 did not quite follow X3J11's
recommendations, apparently adopting a different view of feature flags,
and from what David has said I gather that the repeated message from X3J11
to 1003 to not further pollute the standard headers has gotten lost.
For NEW facilities (i.e. not those inherited from historic implementations
of UNIX), use new, distinct headers for defining new interfaces; don't add
new symbols (whether or not under control of feature flags) to standard C
headers. Please!
Volume-Number: Volume 27, Number 101
Technical Details
Message-ID:
<1992Feb22.073646.18830@uunet.uu.net>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<1992Feb12.221447.2080@uunet.uu.net> <1992Feb18.204251.3356@uunet.uu.net> <1992Feb19.202414.8126@uunet.uu.net>Show Full Headers
Complete Article Headers
Received: from rodan.UU.NET by ftp.UU.NET with SMTP (5.61/UUNET-guest-mail-drop) id AA23817; Sat, 22 Feb 92 02:51:06 -0500 Received: from relay2.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25315; Sat, 22 Feb 92 02:50:01 -0500 Received: from kithrup.COM by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16389; Sat, 22 Feb 92 02:49:59 -0500 Newsgroups: comp.std.unix From: Chesley Reyburn <cmr@cvedc.prime.com> Subject: Re: POSIX question: dynamic linking Message-ID: <1992Feb22.073646.18830@uunet.uu.net> Originator: sef@ftp.UU.NET Keywords: POSIX dynamic linking Nntp-Posting-Host: ftp.uu.net X-Submissions: std-unix@uunet.uu.net Organization: Computervision R&D, Beaverton OR References: <1992Feb12.221447.2080@uunet.uu.net> <1992Feb18.204251.3356@uunet.uu.net> <1992Feb19.202414.8126@uunet.uu.net> Date: Thu, 20 Feb 1992 17:47:39 GMT 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. Status: R