jsh@usenix.org (Jeffrey S. Haemer) (12/03/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.1: System services interface Update
Mark Doran <md@inset.co.uk> reports on the October 16-20, 1989 meeting
in Brussels, Belgium:
P1003.1 is now a full-use standard, so interest in attending the
working group has wained somewhat. Attendance didn't get above
fifteen or so all week and was nearer half a dozen most of the time.
Even so, this was a bit low by comparison with recent meetings. So
where was everyone?
[Editor's note -- Notice that this is larger than the attendance at
typical meetings of, for example, dot nine. "Low attendance" is
relative.
Author's additional note -- And that's the frightening thing;
standards being established by as few as half a dozen _i_n_d_i_v_i_d_u_a_l_s.
This cannot be representative or balanced. Scary stuff, "...as we
take you on a journey, into the Standards Zone..."]
We were all lead to believe that meeting in Brussels was going to
further the cause of international participation in the POSIX process.
Several people I would normally expect to see, didn't show; Europe
must be too far from home for a lot of the regulars. Unfortunately,
neither did I see more than two or three European types (whom I would
not normally expect to see at POSIX) all week either. Oh well, I'm
sure it was a good idea really...
So what did those that showed get up to? Well, in chronological
order:
1. ISO 9945 Status and Document Format
2. P1003.1a Balloting
3. Transparent File Access
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.1: System services interface
- 2 -
4. Language-Independent Specification
5. Messaging
6. P1003.1b
In detail:
1. ISO 9945
[Editor's note -- ISO 9945 is, roughly, the ISO standard
engendered by and corresponding to the POSIX work.]
It looks like 9945 is going to be split up into three major
pieces, the first of which is founded upon the IEEE P1003.1-1988
standard. This piece is likely to include all the other system
interfaces as well (notably, the real time stuff from P1003.4).
The other two pieces will be based around utilities and system
administration.
The basic IS9945-1:1989 will be just the same as the regular,
ugly-green, dot-one book -- well almost. ISO has yet another
documentation format and the book will have to be squeezed to
fit it. And before you ask, this one doesn't allow line numbers
either. We are assured that making the changes is not a major
problem, but the working group has still requested a new
disclaimer telling readers that all mistakes are the fault of
ISO!
2. P1003.1a
[Editor's note -- This document (supplement A) is supposed to
contain clarifications of and corrections to P1003.1-1988, but
no substantive changes.]
The meeting discussed resolution issues from the first ballot.
Highlights included:
- the decision to withdraw the cuserid() interface; its loss
will not be sadly mourned since one can use other
interfaces to do the same job better.
- the addition of a new type name ssize_t (yes, two s's) to
represent signed size_t values; this has all sorts of uses
-- for example, in the prototype for read(). Currently,
the parameter specifying the number of bytes to be read()
is given as a size_t, but read() has been specified to
December 1989 Standards Update IEEE 1003.1: System services interface
- 3 -
return an int, which this may not be large enough to hold a
size_t character count. Moreover, read() may return -1 for
failure, or the number of characters read if the call was
successful.
The recirculation ballot happened between November 10-20; if you
care but didn't know that already, it doesn't matter because you
(and many others, I suspect) have missed your chance. This all
seems a bit fast but it does mean that P1003.1a will hit an ISO,
six-month, letter-ballot window; standards must progress you
know...
3. Transparent File Access
Isn't this a P1003.8 problem? Yes, but the chair of the TFA
committee came to talk about TFA semantics as they relate to
P1003.1.
The crux of the matter is that the TFA folks (all six of
them...) seem to have decided that standardizing NFS will do
nicely for TFA. Their chair wonders whether the rest of the
world (or, more accurately, the balloting group for a TFA
standard) will agree.
The answer from the dot one folks appears to be definitely not
(thank goodness)! There appear to be several arguments against
NFS as the TFA standard from dot one. These include:
- It is impossible to maintain full dot one semantics over a
network using NFS. Consider the last-close semantics, for
example, which can only be preserved over a network using a
connection-oriented protocol, which NFS is not.
- Transparent File Access should be _t_r_a_n_s_p_a_r_e_n_t; NFS isn't.
It is possible for operations that are logically sound to
fail because of network timeouts.
- NFS is a _d_e _f_a_c_t_o standard; why should it get an official
rubber stamp?
This appears to be a hot topic that many groups may have an
interest in, so there will be an "out-of-hours" meeting on TFA
at the New Orleans POSIX -- If you care at all, I suggest you
try to show up... [Editor's note -- If you do care but can't go
to New Orleans, we suggest either writing directly to the TFA
chair, Jason Zions <jason@hpcndr.cnd.hp.com>, or posting your
opinions to comp.std.unix.]
December 1989 Standards Update IEEE 1003.1: System services interface
- 4 -
4. Language-Independent Specification
It seems to have been decided that POSIX API standards should be
written in a language-independent form, i.e. not expressed in
C-language constructs.
My initial reaction was one of horror, but then someone quietly
pointed out to me that C is not the only programming language in
the known universe. This I have to concede, along with the idea
that bindings to POSIX APIs in other languages may not be such a
bad idea after all. Indeed work is well underway to produce
FORTRAN and ADA bindings.
But now it seems we have to express POSIX in a language-
independent way. "Why?" I ask... Well, this means that when
you come to write the next set of actual language bindings, the
semantics you'll need to implement won't be clouded with
language-dependent stuff; the idea is that you won't have to
understand C in all its "glory" to write new language bindings.
So what will the language-independent specifications look like?
Will I be able to understand those? The current proposal
doesn't look like anything I recognize at all. Yes, that's
right, we have to learn a whole NEW language (sigh). Why not
use a more formal specification language that a few people know?
(Like ASN.1 for example, which P1003.7 has decided to use.)
Better yet, why not use constrained English -- lots of people
can read that...
Come to think of it, since the FORTRAN and ADA bindings folks
have managed without the aid of language-independent
specifications, why can't everyone else? Is there more to this
than a glorified job creation scheme? ("Wanted: expert in POSIX
'language-independent' language...") If there is, do we have to
invent a new wheel to get the job done?
As you can tell, my opinion of this effort is somewhat
jaundiced. Perhaps, you may say, I have missed the point.
Maybe so; but if I have, I feel sure that some kind soul will be
only too happy to correct me in "flaming" detail :-)
5. Messaging
The UniForum internationalization (I18N) folks brought forward a
proposal for a messaging facility to be included in P1003.1b.
The working group decided that it needs some more work but will
go into the next draft.
[Editor's note -- The problem being solved here is that
internationalized applications store all user-visible strings in
external files, so that vendors and users can change the
December 1989 Standards Update IEEE 1003.1: System services interface
- 5 -
language of an application without recompiling it. The UniForum
I18N group is proposing a standard format for those files.]
6. P1003.1b
Work on production of the second supplement is still at a
formative stage. Indeed, the group is still accepting formal
proposals for functionality to add to the document. Where
P1003.1a has been drawn up as a purely corrective instrument,
P1003.1b may add new functionality. Among the interesting
things currently included are these:
- The messaging proposal described above.
- A set of interfaces to provide symbolic links. The basic
idea is that lstat(), readlink() and symlink() operate on
the link, and all other interfaces operate on the linked-to
file.
Rationale will be added to explain that '..' is a unique
directory, which is the parent directory in the same
physical file system. This means that cd does not go back
across symlinks to the directory you came from.
This is the same as the semantics on my Sun. For example:
(sunset) 33 % pwd
/usr/spare/ins.MC68020/md/train
(sunset) 34 % ls -ld ./MR_C++
lrwxrwxrwx 1 root 32 Sep 30 1988 MR_C++ -> /usr/sunset/md/c++/trainset/c++/
(sunset) 35 % cd MR_C++
(sunset) 36 % pwd
/usr/sunset/md/c++/trainset/c++
(sunset) 37 % cd ..
(sunset) 38 % pwd
/usr/sunset/md/c++/trainset
The rationale is meant to help keep readers' eyes on what's
really written in the standard and help them avoid
misinterpreting it along lines of their own potential
misconceptions.
- P1003.1b used to have two descriptions of Data Interchange
formats. Now it has only one. The working group picked
the one that remains because it more closely existing
December 1989 Standards Update IEEE 1003.1: System services interface
- 6 -
standards in the area, in particular the surviving proposal
refers to X3.27.
December 1989 Standards Update IEEE 1003.1: System services interface
Volume-Number: Volume 17, Number 82std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/05/90)
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn> >... the P1003.1 working group decided that split baud rates are not >important enough to require explicit support for them in the standard. In the original 1003.1 discussions, I recall that we did not want to MANDATE that different split baud rates be supported, since many existing systems could not do so, but that we did want to ALLOW them to be supported in environments that could do so. Thus a request to set differing split baud rates may fail (as many almost any I/O system call), if the hardware or port handler code is not up to it. If this decision has been changed I'd like to know why. Volume-Number: Volume 19, Number 72
guy@auspex.uucp (Guy Harris) (04/06/90)
From: guy@auspex.uucp (Guy Harris)
>(``What are split baud rates?'' the American reader is asking.
Which is kind of amusing; they were put into one of the "termios"
section drafts at the suggestion of a Canadian, and the person who
initially put them in there was a US citizen who was quite aware that
UNIX (a system most if not all of whose original creators were also US
citizens) used to support them....
UNIXes with a V7-flavored tty driver (V7 itself, BSD) supported them;
the people who did the S3 tty driver decided not to include support for
them.
It seems that much newer hardware doesn't support them - serial port
chips don't seem to allow the input and output baud rate to be set
separately - but older hardware did. Do systems sold in Europe have
serial port chips that support split baud rates?
Volume-Number: Volume 19, Number 54henry@zoo.toronto.edu (04/07/90)
From: henry@zoo.toronto.edu >From: peter@ficc.uucp (Peter da Silva) >What about Eric Allman's "parseargs" (or my modified version), which have >finally fulfilled the promise of "getopt" to make argument parsing easy? What about it? I fear it's a bit late and not sufficiently widely used to make it into POSIX, which is (mostly) supposed to be standardizing existing practice. [I'm among those who takes a dim view of the explosive growth of POSIX committees working on standards for subjects we don't even understand yet.] I suspect it would also be controversial, since some of us think getopt() does most of what's really needed. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu Volume-Number: Volume 19, Number 70
jsh@usenix.org (06/29/90)
From: <jsh@usenix.org>
An Update on UNIX*-Related Standards Activities
June, 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.1: System services interface
Paul Rabin <rabin@osf.org> reports on the April 23-27 meeting in Salt
Lake City, UT:
1. Introduction
The POSIX 1003.1 working group is the oldest POSIX group, responsible
for specifying general-purpose operating system interfaces for
portable applications. This group developed the original 1988 POSIX
standard, and is now responsible for writing supplements and revisions
to that standard. This work includes
+ corrections and clarifications to the 1988 POSIX standard
+ material that was too controversial to handle before
+ new interfaces requested by other POSIX working groups
Like other working groups developing ``base standards,'' the 1003.1
working group is responsible for writing both C language and
language-independent versions of the specifications that it develops.
So far, the group has concentrated on the C language versions, but
there is increasing pressure to make progress on the language-
independent specifications.
The working group recently completed a revision of the 1988 POSIX
standard, and is currently working on a supplement to that revision.
There has been a lot of turnover in the group since the 1988 POSIX
standard was completed, but there are still a few old-timers to
provide continuity. About 15 people attended the last two meetings.
This seems to be a good size for getting work done. This is
definitely a technical crowd; check your politics at the door.
For more information about the group and how to participate, contact
the chair, Donn Terry, at donn@hpfcla.fc.hp.com or hplabs!hpfcla!donn.
__________
* UNIXTM is a Registered Trademark of UNIX System Laboratories in
the United States and other countries.
June, 1990 Standards Update IEEE 1003.1: System services interface
- 2 -
Send comments and proposals to the secretary, Keith Stuck, at
keith@sp7040.uucp. I've made this report a bit more detailed than
usual in order to give the technical details wider exposure. New
proposals, and comments on any of the current active proposals or
issues are welcome.
2. 1003.1a Status
1003.1a is the recently completed revision to the 1988 POSIX standard.
No new interfaces or features were introduced, but the text was
revised in several ways. The main reason for the revision was to
prepare the text for balloting as an ISO standard, so the document had
to be made to look like an ISO standard. This meant adding ISO
boiler-plate, changing external document references to pretend that
only standards exist, changing internal cross-references so that
chapters are renamed sections, and sections are renamed clauses and
subclauses, changing ``will'' to ``shall,'' etc., ad nauseam. While
the working group was having fun with all that, they took the
opportunity to do some cleaning up. They corrected errors, clarified
unclear language, and changed the function synopses to use ANSI C
prototypes. The group did make one normative change, which was to
specify reserved namespaces. This will allow implementations and
revisions to the standard to define extensions without breaking
existing, conforming applications. It's messier than you might think.
After four recirculation ballots, IEEE balloting was completed in
April. Now it has to get through the ISO balloting process. See the
recent snitch report on 1003.5 for a description of how IEEE and ISO
balloting is synchronized, and what all of the acronyms mean.
ISO has been balloting 1003.1a as ISO/IEC DIS 9945-1. After the first
ISO ballot, JTC1 approved 9945-1 for promotion to full IS status.
This approval was overruled by the ISO Central Secretariat on the
grounds that the document format was still not satisfactory (still
haven't caught all of those ``will''s). Rather than publish the
current document and then immediately revise, ballot, and publish it
again, it was decided to create a new DIS and to start a second round
of ISO balloting. This will cause a delay in the publication of the
international POSIX standard (and hence also the IEEE POSIX.1
standard). The U.S. Technical Advisory Group (TAG) is responsible for
generating the U.S. ballot. Assuming that no normative changes are
introduced by the ISO balloting process, the resulting document will
be published by IEEE as IEEE Std 1003.1-1990.
June, 1990 Standards Update IEEE 1003.1: System services interface
- 3 -
3. 1003.1b Status
Since 1003.1a is now out of IEEE's hands, the working group spent the
Utah meeting working on 1003.1b, the first supplement to 1003.1a.
This will include some corrections and clarifications that didn't make
it into 1003.1a, but will mainly consist of new interfaces and
features.
1003.1b has been in the works for several meetings, so the draft
already contains a lot of material. The first day was devoted to
revision of the draft, the rest of the week to considering new
proposals. The previously announced schedule for 1003.1b specified
the Utah meeting as the cutoff date for new proposals. Unfortunately,
some expected proposals were not received, and some that were received
were not ready for incorporation, so the cutoff was deferred until the
next meeting, in Danvers, Massachusetts.
Draft 2 of 1003.1b was distributed just before the meeting in Utah.
Draft 3 should be available before the Danvers meeting. 1003.1b is
expected to be approved sometime in early 1991, and to be published by
IEEE as a separate supplement to the IEEE Std 1003.1-1990.
3.1 New Features in the Current Draft of 1003.1b
Draft 2 of P1003.1b includes a new data interchange format, and new
interface specifications for symbolic links, environment list access,
and file-tree walking. These had been proposed and generally accepted
at previous meetings. Many new issues were raised and discussed.
3.1.1 Symbolic_Links P1003.1b adds BSD symbolic links to the 1988
POSIX standard as a new required feature. New interfaces for
symlink(), readlink(), and lstat() are specified, and the definition
of pathname resolution is amended to include the handling of symbolic
links. Implementations may optionally enforce a limit on the number
of symbolic links that can be tolerated during the resolution of a
single pathname, for instance to detect loops. The new symbol
{_POSIX_SYMLOOP} is defined to be the minimum value of such a limit.
A new error, [ELOOP], is returned if such a limit is exceeded.
Symbolic links that are encountered in pathname prefixes are always
resolved. Symbolic links named by the final component of a pathname
will be resolved or not, depending on the particular interface. By
default, such symbolic links will be resolved, unless specified
otherwise. The interfaces that will not resolve symbolic links named
by pathname arguments are:
+ readlink()
If the pathname argument names a symbolic link, the contents of
the link will be returned.
+ lstat()
If the pathname argument names a symbolic link, a stat structure
will be returned for the link itself.
June, 1990 Standards Update IEEE 1003.1: System services interface
- 4 -
+ unlink()
If the pathname argument names a symbolic link, the link itself
will be removed.
+ rmdir()
If the pathname argument names a symbolic link, the link will not
be followed and the call will fail.
+ open()
Symbolic links are followed, unless both O_CREAT and O_EXCL are
set. If both O_CREAT and O_EXCL are set, and the pathname
argument names an existing symbolic link, the link will not be
followed and the call will fail.
+ link()
If the new pathname names a symbolic link, the link will not be
followed and the call will fail. If the old pathname names a
symbolic link, the link will be followed. This is the BSD
behavior. SVR4.0 does not follow the link in this case, thus
supporting hard links to symbolic links. The working group felt
that the SVR4 behavior unnecessarily restricts implementations
(for instance, those that do not implement symbolic links with
inodes), and has much more complex semantics.
+ rename()
If the old pathname names a symbolic link, the link will not be
followed. Instead, the symbolic link itself will be renamed. If
the new pathname names a symbolic link, it will not be followed.
Instead, the symbolic link will be removed, and a new hard link
will be created naming the file that was previously named by the
old pathname.
The 1988 POSIX standard specifies that if the new pathname names
an existing file, rename() will fail if the new and old pathnames
do not either both name directories or both name non-directory
files. This rule needs to be expanded to include the case of the
new pathname naming a symbolic link. Should the rename() call
fail depending on whether or not the symbolic link named by the
new pathname itself names a directory or a non-directory file?
This will be resolved at the next meeting.
Symbolic links are not required to have any attributes other than
their file type and their contents. This is intended to provide the
simplest semantics and to allow the greatest latitude for
implementations.
3.1.2 Other_BSD_Interfaces P1003.1b also includes specifications for
the following interfaces:
June, 1990 Standards Update IEEE 1003.1: System services interface
- 5 -
+ fchmod()
+ fchown()
+ fsync()
+ ftruncate()
3.1.3 Environment_List The ANSI-C standard defines the getenv()
function to retrieve the value corresponding to a given name in a
program's environment list, but does not specify the implementation or
initialization of that list. The 1988 POSIX standard specified the
traditional list implementation using the external variable environ,
and specified the initialization of the list by the exec functions.
In an attempt to extend the set of high-level interfaces to the
environment list, and to pave the way for the possible eventual
removal of environ, the working group has included putenv() and
clearenv() interfaces in 1003.1b. Three problems have been identified
with these high-level interfaces:
+ They cause static data to be shared between the application and
the implementation. Neither the application nor the
implementation can easily manage the storage for environment
"name=value" strings.
+ They are not robust. The interactions between the high-level
interfaces and access via environ is not specified.
+ They can't be easily extended to handle multiple lists. There is
no way to copy a list, or to build a new list for execle() or
execve().
The putenv() and clearenv() interfaces may be removed from 1003.1b at
the next meeting if a revised proposal does not appear.
3.1.4 File_Tree_Walk The 1003.1 working group promised the 1003.2
group (Shell and Utilities) that a mechanism would be provided for
walking an directory tree of unbounded depth using any given (non-
zero) number of free file descriptors. The Berkeley folks have
implemented a set of high-level interfaces defined by David Korn of
Bell Labs, and proposed them for inclusion in 1003.1b. These
interfaces support every option and search order required by the
1003.2 commands. The 1003.1 group wants a simpler interface suitable
for typical application programs, so Keith Bostic will put the
proposal on a ``weight-reducing diet'' and resubmit it for the next
draft.
The high-level file-tree walk interfaces can be implemented using only
the existing 1003.1 interfaces. Since 1003.1 does not define a
portable way to save and restore file position for a directory and
cannot hold a file descriptor open for each directory level, the
June, 1990 Standards Update IEEE 1003.1: System services interface
- 6 -
implementation must read and save all directory entries each time a
new directory is visited. This requires only a single file descriptor
(or whatever resource is used by by opendir()). If the underlying
system does provide a way to save and restore file position for
directories, the file-tree walk implementation can use it to reduce
memory consumption.
There was a discussion about whether it is possible (and preferable)
to improve the low-level directory interfaces instead of adding new,
high-level interfaces. Do the high-level interfaces really add new
functionality for portable applications? Do they belong with the
low-level operating system interfaces specified in 1003.1?
Walking an unbounded file tree requires an unbounded number of
directory file positions to be supported using a bounded number of
file descriptors. Either seekdir() and telldir() are needed, or an
unbounded number of opendir()'s must use a bounded number of file
descriptors. The working group has already rejected seekdir() and
telldir() because they cannot easily be supported on implementations
that use a non-linear directory format. A prohibition of simple
implementations of opendir() using file descriptors is also likely to
be rejected.
The underlying problem is that the orderedness of directory entries
was implicit in the traditional implementations, but was not made
fully explicit in 1003.1, partly out of a desire to permit alternate
implementations (for instance, b-trees). As a result, orderedness
must now be imposed by the application. On a non-linear directory
implementation, if positioning is not supported, even opendir() must
read in the whole directory.
3.1.5 Data-Interchange_Format The 1988 POSIX standard specified two
data-interchange formats based on existing utilities. These define
the data-stream encoding of a sequence of files, together with their
pathnames and other attributes. The first format is based on tar and
encodes files as a stream of 512-byte blocks. The second format is
based on cpio and encodes files as an unblocked byte stream.
The ISO POSIX group (JTC1/SC22/WG15) pointed out that both of these
formats are incompatible with accepted international and U.S.
standards. After some arm twisting, the 1003.1 working group agreed
to devise a new data interchange format based on IS 1001: 1986, which
is more or less equivalent to ANS X3.27-1987, the familiar ANSI
labeled tape format.
The current draft of 1003.1b includes the framework for the new
specification, but a lot more work is needed. Previous meetings
discussed alternate proposals. The topic has been strangely quiet
lately, considering the confusion that may be expected when it goes to
ballot. It wasn't discussed at the Utah meeting at all.
June, 1990 Standards Update IEEE 1003.1: System services interface
- 7 -
3.2 {_POSIX_PATH_MAX}: A Clarification
The 1988 POSIX standard included two conflicting statements regarding
{PATH_MAX} and {_POSIX_PATH_MAX}: one said that the null was included
in the count; the other said that the null was excluded. Traditional
implementations have included the trailing null; some new
implementations have excluded the null.
One alternative or the other had to be endorsed. The working group
decided that {_POSIX_PATH_MAX} should not include the trailing null,
since specifying this will not break currently conforming
applications.
3.3 Headers and Name-Space Control
Since 1003.1b is adding many new identifiers to the standard, there
was discussion about whether new identifiers should be declared in new
headers, or whether existing headers could be used, with new feature-
test-macros to control visibility of the additional identifiers. It
was agreed that although both headers and feature-test macros control
identifier visibility, their functions are complementary. Headers are
appropriately used to divide name-spaces horizontally, by
functionality. Feature-test macros are appropriately used to divide
name-spaces vertically, by specification level.
With this understanding, the group decided that new identifiers will
be declared in the ``right place.'' A new header will be created only
if no existing header is functionally appropriate.
A new feature-test macro will be specified by 1003.1b and subsequent
revisions: _POSIX_1_SOURCE. This macro takes ordinal values, starting
with 2 for 1003.1b, and will be incremented by 1 for every subsequent
revision. If the value is 1, the effect will be the same as if
_POSIX_SOURCE were defined.
There are two changes here. The new name was used to indicate that
the macro only controls the visibility of identifiers defined in
POSIX.1. The usage was changed to allow the value to indicate the
particular revision or supplement to the standard, rather than having
to create a new macro each time. This should simplify the
construction and maintenance of header files.
3.4 Requests
Two requests were made by vendors trying to support POSIX behavior on
non-UNIX file systems:
+ that {_POSIX_LINK_MAX} be reduced from 6 to 2
+ that {_POSIX_PATH_MAX} be reduced from 255 to 252
June, 1990 Standards Update IEEE 1003.1: System services interface
- 8 -
Both requests were rejected. Either of these changes could have made
existing conforming applications non-conforming. Even where the risk
of breaking applications seemed small, the working group was reluctant
to set a precedent without a pretty good rationale to protect them
against similar requests in the future.
3.5 New Proposals
Five proposals for new interfaces were submitted for inclusion in
1003.1b, many of which provoked lively discussion. Some were
accepted, some were rejected, and others were deferred to allow a
revised proposal to be submitted or to allow more time for
consideration.
3.5.1 seteuid(),_setegid() Bob Lenk and Mike Karels proposed a set
of changes to the way the effective user and group id's are handled,
in order to provide better support for setuid/setgid programs.
+ Require that all implementations support the functionality of the
saved user ID and saved group ID. These process attributes are
set by the exec functions and by privileged calls to setuid() and
setgid().
+ Add seteuid() and setegid() as new functions that change only the
effective user ID and effective group ID, respectively. A change
is allowed if the proposed new user/group ID is the same as
either the real user/group ID or the saved user/group ID.
+ Redefine the {_POSIX_SAVED_IDS} option to apply only to non-
privileged calls to setuid() and setgid().
This proposal has general support in the working group, and will be
included in the next draft of 1003.1b.
The discussion of this proposal led to a general lament about how
unclear the group model is in the 1988 POSIX standard, perhaps the
result of a hasty marriage between the System V and BSD models. At
the next meeting, the working group intends to add new text to
P1003.1b to clarify the relation between the effective group ID and
the supplementary group list.
3.5.2 Magnetic_Tape_Support The 1003.10 working group
(Supercomputing Profiles) proposed new interfaces to support basic
controller functions for magnetic tape drives, based on the ioctl()
commands supported in 4.3BSD. Although support for these interfaces
would be optional in 1003.1b, the working group decided that the
functions should be further specified according to whether they are:
+ required for all types of tape drives;
June, 1990 Standards Update IEEE 1003.1: System services interface
- 9 -
+ required only for 9-track tape drives;
+ required only for cartridge tape drives; or
+ optional on all types of tape drives.
The proposal needed further revision, but was generally supported by
the working group.
The submitted proposal also included interfaces for mounting labeled
tape volumes. These were considered to be inappropriate for inclusion
at this time and will be deferred until a later revision of the
standard.
3.5.3 Checkpoint/Restart The 1003.10 working group also proposed new
(optional) interfaces for checkpointing and restarting processes.
This proposal is based on two existing implementations. The
interfaces are intended to protect very-long-running applications from
both scheduled shutdowns and unexpected failures of the system.
The 1003.1 working group was not happy to have to deal with this and
had lots of questions. Were programming interfaces for portable
applications really needed, or was a command interface sufficient?
How much state needed to be saved in the checkpoint? What if the
processes depended on additional state information that was not in the
checkpoint, such as file data or the states of other communicating
processes or devices? In this case, the restart would only be
successful if this additional state had not changed since the
checkpoint. How could such changes be detected or prevented? What is
the set of interfaces that an application can use and be sure that it
can be checkpointed and restarted successfully, without dependencies
on additional state? Should applications have a mechanism for
checkpointing themselves, or for blocking an external request that
they be checkpointed?
Because a checkpoint/restart mechanism will have a major impact on
implementations, and the requirements are not yet clear, the working
group was unwilling to endorse the current proposal. A task force
made up of representatives of the 1003.1 and 1003.10 working groups
will be created to clarify the requirements and revise the proposal.
This proposal is going to need a lot more discussion, so checkpoint
restart interfaces will almost certainly not be included in P1003.1b,
but they may be adopted in a subsequent revision.
3.5.4 Messaging The UniForum proposal for new messaging interfaces
has been before the 1003.1 working group for a couple of meetings now.
The proposed interfaces are intended as replacements for the message
catalog interfaces specified in XPG3, and differ from those in several
ways (since the discussion was fairly contentious, I'll try to be
objective):
June, 1990 Standards Update IEEE 1003.1: System services interface
- 10 -
+ The XPG3 interfaces identify a message by the triple: <catalog
name, set ID, msg ID>, where catalog name is a file name, and set
ID and msg ID are integers. The UniForum interfaces identify a
message by the triple: <locale name, domain name, message name>,
where locale name, domain name, and message name are all strings.
The locale for messages is specified by the new LC_MESSAGES
category of the locale. Advocates of the UniForum proposal claim
that string identifiers are easier to use and are more robust
against errors during application development and maintenance.
+ In the XPG3 scheme, each message catalog is an ordinary file.
Message catalogs must be specified by filename and explicitly
opened before messages can be retrieved. The NLSPATH environment
variable provides a search path for message catalogs that can be
parameterized by (among other things) the language, territory,
and codeset fields of the LANG environment variable. In the
UniForum scheme, groups of messages are specified by an abstract
``domain.'' A default domain can be set to control message
accesses, or the domain can be explicitly specified for an
individual message access. Advocates of the UniForum proposal
claim that the binding of message catalogs to files unnecessarily
restricts implementations and imposes a more complex interface on
application developers.
+ The XPG3 interface includes an additional string argument that is
returned in case no message specified by <set ID, msg ID> can be
retrieved from the message catalog. In the UniForum proposal,
the message name itself is returned if the message cannot be
found. Advocates of the UniForum proposal point out that the
message name string makes a separate, ``default'' message string
unnecessary.
In addition, the UniForum proposal includes a specification of the
message source file format that differs from the format specified in
XPG3.
+ In the XPG3 format, message strings are implicitly delimited: at
the beginning by the preceding message ID followed by a single
space or tab character, and at the end by an unescaped newline.
In the UniForum format, all strings, including domain names,
message ID's, and message strings, are explicitly delimited by
double quotes ("). Adjacent strings separated by white-space
characters are concatenated. Advocates of the UniForum proposal
claim that the new format provides better support for multi-line
strings and for leading and trailing white-space characters in
strings.
+ In the XPG3 format, the message ID and its corresponding message
string are implicitly determined by their position on a source
line. In the UniForum format, explicit directives are provided
for message ID's and message strings. Advocates of the UniForum
June, 1990 Standards Update IEEE 1003.1: System services interface
- 11 -
proposal claim that the new format is extensible. New attributes
may be added to message entries, such as screen coordinates or
font size.
+ The XPG3 format includes directives for deleting individual
messages and sets of messages, and the associated gencat utility
takes no switches. In the UniForum proposal, all deletion
semantics are provided by switches on the associated gentext
utility.
There was much discussion of the interfaces; less about the source
file format. The most divisive issue was whether string message ID's
are preferable to numeric message ID's. Among those who felt that the
new interfaces are better, there was disagreement about whether the
advantages outweighed the cost of conversion for applications and
implementations based on the XPG3 interfaces. The rationale
accompanying the UniForum proposal described several ways to convert
applications from the XPG3 interfaces to the proposed new interfaces.
The working group asked X/Open to submit the XPG3 messaging interfaces
as an alternate proposal, since they represent existing practice, and
X/Open has agreed to do so. X/Open has said that they will follow
POSIX if POSIX endorses a different interface. The decision regarding
which, if any, messaging proposal to include in 1003.1b will be made
at the POSIX meeting in Danvers.
It's hard to predict the fate of this proposal. The UniForum proposal
represents the consensus of one of the leading internationalization
working groups and is reported to have some support within X/Open. On
the other hand, the POSIX working groups are obliged to respect
existing practice. Watch this space.
3.5.5 /dev/stdin,_/dev/fd/n,_etc. There was an unofficial proposal
from members of the 1003.2 working group that open() be extended to
recognize the special strings "/dev/stdin", "/dev/stdout",
"/dev/stderr", and "/dev/fd/n", and return a new file descriptor
dup()'ed from STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO, or file
descriptor n, respectively. This proposal was intended to allow
simplified command line parsing, by eliminating special casing for
``-'' and ``--'' arguments. The proposal was rejected after a short
exploration of the possible semantics of these pathnames when used
with link(), rename(), etc..
4. Conclusion
As you can see, there's a lot going on. Even though most of the
attention has shifted to other working groups, the 1003.1 group is
busy revising and extending the 1988 standard. The group is small
now, by POSIX standards, but their work is as important as ever.
June, 1990 Standards Update IEEE 1003.1: System services interface
Volume-Number: Volume 20, Number 56gwyn@smoke.brl.mil (Doug Gwyn) (06/30/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> >There was a discussion about whether it is possible (and preferable) >to improve the low-level directory interfaces instead of adding new, >high-level interfaces. Do the high-level interfaces really add new >functionality for portable applications? Do they belong with the >low-level operating system interfaces specified in 1003.1? No, definitely not. However, they would be appropriate at the 1003.2 level. Note that 1003.2 implementations are not constrained to use only 1003.1 facilities, so the fact that it's hard to implement tree walkers right using the existing 1003.1 directory access functions is no argument against defining tree walkers as part of a higher level. >The ISO POSIX group (JTC1/SC22/WG15) pointed out that both of these >[tar, cpio] formats are incompatible with accepted international and U.S. >standards. After some arm twisting, the 1003.1 working group agreed >to devise a new data interchange format based on IS 1001: 1986, which >is more or less equivalent to ANS X3.27-1987, the familiar ANSI >labeled tape format. The ANSI magtape format is simply inappropriate. UNIX archives were designed to be single files, making it simple to transport them by means other than magnetic tape. In this modern networked world, for the most part magnetic tape is an anachronism. Any archive format standard for UNIX should not depend on the archive supporting multiple files, tape marks, or any other non-UNIX concept. It is to the credit of UNIX's original designers that they did NOT blindly adopt existing standards when they were technically inferior. Let's not make the POSIX standards impose conventional-think upon UNIX environments.. Volume-Number: Volume 20, Number 69
ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe) (06/30/90)
Moderator!: Delete most of these lines (begin): Return-Path: <uunet!goanna.cs.rmit.OZ.AU!ok> Submitted-From: uunet!goanna.cs.rmit.OZ.AU!ok (Richard A. O'Keefe) Moderator!: Delete most of these lines (end). From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe) >In <385@usenix.ORG> From: jsh@usenix.org, Paul Rabin <rabin@osf.org> > reports on the April 23-27 meeting in Salt Lake City, UT: >... > There was a discussion about whether it is possible (and preferable) > to improve the low-level directory interfaces instead of adding new, > high-level interfaces. Do the high-level interfaces really add new > functionality for portable applications? Do they belong with the > low-level operating system interfaces specified in 1003.1? In article <754@longway.TIC.COM>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > From: Doug Gwyn <gwyn@smoke.brl.mil> > No, definitely not. However, they would be appropriate at the 1003.2 > level. If I want file tree walking, what's wrong with something on the order of FILE *files_selected = popen("find ......"); Presumably popen() and 'find' have to be in 1003.2 anyway. There is precisely one reason why I can't use this right now, and that is that 'find' doesn't quote its output, so if there is a file name with an embedded \n things break. That might be addressed by any number of methods; one simple method would be to add a -length subcommand which would do the equivalent of printf("%d %s\n", strlen(pathname), pathname); where the existing -print subcommand does the equivalent of printf("%s\n", pathname); If I understand Doug Gwyn correctly, that's the kind of thing he has in mind. It is, after all, no more than the traditional UNIX Way. By the way, I don't quite understand the file tree walking problem. Unless one has some absolutely compelling reason for requiring a depth-first search and not using /tmp files, something like 'find' can be done using - one file descriptor to send file names to (used sequentially) - one file descriptor for a work file (random access) - one directory descriptor or whatever (each directory being opened once, scanned once, and never looked at again) Basically you do a breadth-first search of directories, using the work file to hold the queue. If you want some other order, sort the output. This is, of course, vulnerable to directories being renamed while the walk is in progress, but so is a depth-first walker that can't hang on to all the directories in the current branch. -- "private morality" is an oxymoron, like "peaceful war". Volume-Number: Volume 20, Number 76
peter@ficc.ferranti.com (peter da silva) (07/02/90)
From: peter@ficc.ferranti.com (peter da silva) In article <754@longway.TIC.COM> From: gwyn@smoke.brl.mil (Doug Gwyn) > The ANSI magtape format is simply inappropriate. UNIX archives were > designed to be single files, making it simple to transport them by > means other than magnetic tape. In this modern networked world, for > the most part magnetic tape is an anachronism. Any archive format > standard for UNIX should not depend on the archive supporting > multiple files, tape marks, or any other non-UNIX concept. I disagree. There are just too many organisations using ANSI format magtapes. Tar and CPIO should both be retained, but the ability to read and write standard ANSI magtapes... if the hardware is available... should be part of a portable operating system standard. So for that matter should such things as different receive and transmit baud rates (ever hear of V.23 modems?), but that's another point. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 82
gwyn@smoke.brl.mil (Doug Gwyn) (07/03/90)
From: Doug Gwyn <gwyn@smoke.brl.mil>
In article <767@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes:
-In article <754@longway.TIC.COM> From: gwyn@smoke.brl.mil (Doug Gwyn)
-> The ANSI magtape format is simply inappropriate. UNIX archives were
-> designed to be single files, making it simple to transport them by
-> means other than magnetic tape. In this modern networked world, for
-> the most part magnetic tape is an anachronism. Any archive format
-> standard for UNIX should not depend on the archive supporting
-> multiple files, tape marks, or any other non-UNIX concept.
-I disagree. There are just too many organisations using ANSI format magtapes.
-Tar and CPIO should both be retained, but the ability to read and write
-standard ANSI magtapes... if the hardware is available... should be part
-of a portable operating system standard.
We're apparently not talking about the same thing. I was talking about
the POSIX standard for archiving collections of files. There is no
particular reason why that should require use of magnetic tape. I'm not
proposing that ANSI (or ISO) magtape standards not be followed where
appropriate; you could for example put a tar or cpio archive within a
file on an ANSI-labeled magtape. However, you can also put a tar or cpio
archive within a file on a disk, and you can ship it across a network as
a single entity, something that is not possible for ANSI magtapes in
general.
Volume-Number: Volume 20, Number 87eric@egsner.cirr.com (Eric Schnoebelen) (07/03/90)
From: eric@egsner.cirr.com (Eric Schnoebelen)
In article <767@longway.TIC.COM> Peter da Silva writes:
- In article <754@longway.TIC.COM> From: gwyn@smoke.brl.mil (Doug Gwyn)
- > The ANSI magtape format is simply inappropriate. UNIX archives were
- > designed to be single files, making it simple to transport them by
- > means other than magnetic tape.
-
- I disagree. There are just too many organisations using ANSI format magtapes.
- Tar and CPIO should both be retained, but the ability to read and write
- standard ANSI magtapes... if the hardware is available... should be part
- of a portable operating system standard.
ANSI tape can be supported via a set of programs over the
standard Unix system (ConvexOS 8.0 and above do so, along with many
other "mainframe" tape subsystem features) but ANSI labeled tapes are
inappropriate for file archival. With a properly designed ANSI tape
subsystem, it is easy enough to have tar, and cpio (and even
dump/restore) use ANSI labeled tapes, and it can be totally transparent
to the user.
Thus, we have the POSIX standard archive on the ANSI standard
magnetic tape format..
--
Eric Schnoebelen eric@cirr.com schnoebe@convex.com
Churchill's Commentary on Man: Man will occasionally stumble over the
truth, but most of the time he will pick himself up and continue on.
Volume-Number: Volume 20, Number 88YZE6041@vx.acs.umn.edu (david paul hoyt) (07/04/90)
From: david paul hoyt <YZE6041@vx.acs.umn.edu> > With a properly designed ANSI tape > subsystem, it is easy enough to have tar, and cpio (and even > dump/restore) use ANSI labeled tapes, and it can be totally transparent > to the user. And better yet, we'll have a standard way of dealing with multi-volumne tapes. It's hard enough to backup your own multi-gigabyte disk system, let alone send large databases to other (potentially non-unix) systems. david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx Volume-Number: Volume 20, Number 89
henry@zoo.toronto.edu (07/04/90)
From: henry@zoo.toronto.edu >From: peter@ficc.ferranti.com (peter da silva) >I disagree. There are just too many organisations using ANSI format magtapes. >Tar and CPIO should both be retained, but the ability to read and write >standard ANSI magtapes... if the hardware is available... should be part... Uh, Peter, go back and look at what Doug wrote. He never said anything, either positive or negative, about the ability to use ANSI magtapes. The point is that the ANSI magtape format assumes a storage medium which has notions like block boundaries and tape marks, and it is grossly mismatched to the requirement for a Unix archiving format. >...So for that matter should such things >as different receive and transmit baud rates (ever hear of V.23 modems?), >but that's another point. Peter, would it be too much to ask whether you have *read* the standards you are criticizing? 1003.1 supports split baud rates. Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry Volume-Number: Volume 20, Number 91
domo@tsa.co.uk (Dominic Dunlop) (07/04/90)
From: Dominic Dunlop <domo@tsa.co.uk> In article <754@longway.TIC.COM> gwyn@smoke.brl.mil (Doug Gwyn) fulminates > The ANSI magtape format is simply inappropriate. UNIX archives were > designed to be single files, making it simple to transport them by > means other than magnetic tape. In this modern networked world, for > the most part magnetic tape is an anachronism. Any archive format > standard for UNIX should not depend on the archive supporting > multiple files, tape marks, or any other non-UNIX concept. Er. As Jason Zions points out in <770@longway.TIC.COM>, > A significant branch of the UNIX(tm)-system and POSIX research community > believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks > are among the leaders here. I feel only slightly squeamish about accusing > them of having only a hammer in their toolbelt; of *course* everything > looks like a nail! The network as a featureless data stream is another example of the same ``traditional'' thinking in the UNIX community. Actually, the datagram-based schemes favoured in the US (oversimplifying grossly, we Europeans have a preference for connection-based systems which do deliver streams) can provide nice record boundaries, which could in turn be used to delimit labels for the proposed tape archive format (after adding some reliability and sequencing). Just because the format is based on IS 1003 for labelled magnetic tapes does not mean to say that it cannot be used on other media, networks among tham. After all, tar's a format for blocked magnetic tapes, but that hasn't stopped us moving tar archives over networks. -- Dominic Dunlop Volume-Number: Volume 20, Number 96
peter@ficc.ferranti.com (peter da silva) (07/04/90)
From: peter@ficc.ferranti.com (peter da silva) In article <776@longway.TIC.COM> henry@zoo.toronto.edu writes: > Uh, Peter, go back and look at what Doug wrote.... > Peter, would it be too much to ask whether you have *read* the standards > you are criticizing? ... Um, yes. I do seem to have written that with my brain disengaged. Apologies all round. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 99
gwyn@smoke.brl.mil (Doug Gwyn) (07/05/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <781@longway.TIC.COM> uunet!tsa.co.uk!domo@usenix.ORG writes: >After all, tar's a format for blocked magnetic tapes, ... No, it is not. A "tar" archive is merely a stream of bytes, all of whose structure is contained internally. The designers of "tar" and (to a lesser extent) "cpio" archive formats did, however, take into account the blocked nature of such media, so that it would be convenient to use such media to hold the archive. This was entirely appropriate and does not require that such media be used. Volume-Number: Volume 20, Number 97
johnz@grapevine.EBay.Sun.COM (John Zolnowsky ext. 33230) (07/10/90)
From: johnz@grapevine.EBay.Sun.COM (John Zolnowsky ext. 33230) In article <385@usenix.ORG>, jsh@usenix.org writes: > Paul Rabin <rabin@osf.org> reports on the April 23-27 meeting in Salt > Lake City, UT: > > 3.3 Headers and Name-Space Control > > A new feature-test macro will be specified by 1003.1b and subsequent > revisions: _POSIX_1_SOURCE. This macro takes ordinal values, starting > with 2 for 1003.1b, and will be incremented by 1 for every subsequent > revision. If the value is 1, the effect will be the same as if > _POSIX_SOURCE were defined. > > There are two changes here. The new name was used to indicate that > the macro only controls the visibility of identifiers defined in > POSIX.1. The usage was changed to allow the value to indicate the > particular revision or supplement to the standard, rather than having > to create a new macro each time. This should simplify the > construction and maintenance of header files. I recognize that programs must have some way of freezing the ever-growing POSIX namespace, but I have reservations about the approach implicit in the name _POSIX_1_SOURCE. I suspect that the "1" in _POSIX_n_SOURCE refers to 1003.1, as a working group or a standard. This creates a strictly historical binding between a function name and the working group which first needed to define an interface, and this binding will be perpetuated in code. As an example, imagine the goobledeegook when multi-threaded network servers must tree-walk and want to be cognizant of symlinks. Since it is planned that all these standards will be unified under the umbrella of ISO 9945-1 (or whatever future number the C-binding appears unders) it would seem more prudent to have a single feature-test macro, such as _POSIX_C_SOURCE, for which for increasing values expose the entire POSIX function namespace in historical order. This would place no further requirements upon implementations. Applications would be affected only when being modified to use POSIX extensions: they would then have to honor not only the namespace reservation of the extension, but of all of POSIX at the time the extension was standardized. Note that this requirement already exists for any other interfaces added by the working group which added the extension. -John Zolnowsky johnz@EBay.Sun.COM (408)276-3230 Volume-Number: Volume 20, Number 117
jason@cnd.hp.com (Jason Zions) (07/10/90)
From: Jason Zions <jason@cnd.hp.com> > Since it is planned that all these standards will be unified under the > umbrella of ISO 9945-1 (or whatever future number the C-binding appears > unders) it would seem more prudent to have a single feature-test macro, > such as _POSIX_C_SOURCE, for which for increasing values expose the > entire POSIX function namespace in historical order. This would place > no further requirements upon implementations. Applications would be > affected only when being modified to use POSIX extensions: they would > then have to honor not only the namespace reservation of the extension, > but of all of POSIX at the time the extension was standardized. Note > that this requirement already exists for any other interfaces added by > the working group which added the extension. This makes the assumption that there is indeed a single POSIX name space, to which pieces are added by the various working groups. This assumption, while a reasonable one, is in fact not correct. The various 1003.* working groups are *not* developing separate components of an overall, integrated POSIX standard. Each POSIX standard stands alone from all other POSIX standards *except* where that standard deliberately requires dependencies. For example, 1003.2 is intended to be implementable on systems which do not offer a 1003.1-compliant interface. So, a strictly-compliant 1003.2 application *could not* assume the presence of 1003.1 symbols et al., and would be permitted to make use of names otherwise reserved to 1003.1. Hence, there needs to be a separate feature-test macro to activate the 1003.2 name space etc. Worse yet, it appears that one of the POSIX Real Time Profiles may very well require only a subset of 1003.1; how on earth does one represent *that* using the _POSIX_C_SOURCE scheme? Jason Zions Volume-Number: Volume 20, Number 119
decot@hpisod2.cup.hp.com (Dave Decot) (07/12/90)
From: decot@hpisod2.cup.hp.com (Dave Decot) > 2. 1003.1a Status > > 1003.1a is the recently completed revision to the 1988 POSIX standard. > No new interfaces or features were introduced, but the text was > revised in several ways. The main reason for the revision was to This is not technically true. The following new features were added by POSIX.1a: ssize_t - signed version of the size_t type SSIZE_MAX - constant representing maximum value of ssize_t TZNAME_MAX - constant representing maximum length of a timezone name _SC_TZNAME_MAX - sysconf() variable argument for TZNAME_MAX POSIX_TZNAME_MAX - minimum value of TZNAME_MAX on POSIX.1a systems (it's 3) The following features were deleted (but are still permitted): cuserid() - definition conflicted with most existing practice CLK_TCK - non-existent definition imported from ANSI C standard The following interfaces were changed: ssize_t read(int fildes, void *buf, size_t count); ssize_t write(int fildes, const void *buf, size_t count); > The discussion of [the setegid(), etc.] proposal led to a general > lament about how unclear the group model is in the 1988 POSIX standard, > perhaps the result of a hasty marriage between the System V and BSD models. > At the next meeting, the working group intends to add new text to > P1003.1b to clarify the relation between the effective group ID and > the supplementary group list. It seemed rather clear to me. "Whether the effective group ID is included in or omitted from the list of supplementary group IDs is implementation-defined." In all cases when checking permission to access something, both the effective group ID and the list of supplementary group IDs should be compared to the group of the object in question; if either matches, the access should be granted. What were the unclarities that were identified? Dave Decot Volume-Number: Volume 20, Number 122
gwyn@smoke.brl.mil (Doug Gwyn) (07/13/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <9951@cs.utexas.edu> std-unix@uunet.uu.net writes: >From: Jason Zions <jason@cnd.hp.com> >Worse yet, it appears that one of the POSIX Real Time Profiles may very >well require only a subset of 1003.1; how on earth does one represent >*that* using the _POSIX_C_SOURCE scheme? Shouldn't 1003.0 step in here and exert some coordination? 1003.1 was deliberately not split into "levels" a la COBOL, and we meant it. A Real-Time extension could very well exist (say, number 1003.123a) and not require that 1003.1 be specified, but be useless in the absence of some subset of 1003.1 or equivalent, just as a hosted C implementation on UNIX does not specify that open() exist, but secretly requires a function with similar properties in order to be implemented at all. If the problem is that the extension wants to contradict some of 1003.1, then it is an INCOMPATIBLE standard (i.e. one could not specify simultaneous conformance with 1003.1 and 1003.123a), and I thought that standards organizations prohibited that. Volume-Number: Volume 20, Number 126
gwyn@smoke.brl.mil (Doug Gwyn) (07/15/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <9998@cs.utexas.edu> std-unix@uunet.uu.net writes: >From: decot@hpisod2.cup.hp.com (Dave Decot) >The following features were deleted (but are still permitted): > CLK_TCK - non-existent definition imported from ANSI C standard ? Did you also get rid of the times() function? CLK_TCK was left to 1003.1 by X3J11 for their exclusive use in converting times() results to/from seconds. The only thing that SHOULD have been changed is that 1003.1 should not say that ANSI C <time.h> defines CLK_TCK, because it doesn't. CLK_TCK should be defined by a 1003.1 implementation, though. Volume-Number: Volume 20, Number 130