Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1990.06.followups

Text File | 1990-08-02 | 138.5 KB | 3,409 lines

echo 1003.1.a
cat >1003.1.a <<'shar.1003.1.a.8224'
From [e-mail]  Sat Jun 30 01:21:24 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08840; Sat, 30 Jun 90 01:21:24 -0400
Posted-Date: 29 Jun 90 21:33:13 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05298; Sat, 30 Jun 90 00:21:19 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12387; Sat, 30 Jun 90 00:20:56 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 29 Jun 90 21:33:13 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

>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

shar.1003.1.a.8224
echo 1003.1.b
cat >1003.1.b <<'shar.1003.1.b.8224'
From [e-mail]  Sat Jun 30 15:02:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13586; Sat, 30 Jun 90 15:02:44 -0400
Posted-Date: 30 Jun 90 10:28:58 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA24501; Sat, 30 Jun 90 11:20:56 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13909; Sat, 30 Jun 90 11:24:08 cdt
From: Richard A. O'Keefe <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Comp Sci, RMIT, Melbourne, Australia
Date: 30 Jun 90 10:28:58 GMT
Apparently-To: [e-mail]

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:  [e-mail] (Richard A. O'Keefe)


>In <[e-mail]> From: [e-mail], Paul Rabin <[e-mail]>
> 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 <[e-mail]>, [e-mail] (Doug Gwyn) writes:
> From:  Doug Gwyn <[e-mail]>
> 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

shar.1003.1.b.8224
echo 1003.1.c
cat >1003.1.c <<'shar.1003.1.c.8224'
From [e-mail]  Sun Jul  1 23:16:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23099; Sun, 1 Jul 90 23:16:36 -0400
Posted-Date: 2 Jul 90 00:18:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15083; Sun, 1 Jul 90 22:16:33 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18680; Sun, 1 Jul 90 22:30:49 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 2 Jul 90 00:18:32 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From: [e-mail] (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.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 82

shar.1003.1.c.8224
echo 1003.1.d
cat >1003.1.d <<'shar.1003.1.d.8224'
From [e-mail]  Tue Jul  3 12:04:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10298; Tue, 3 Jul 90 12:04:06 -0400
Posted-Date: 3 Jul 90 02:57:47 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01765; Tue, 3 Jul 90 11:04:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23163; Tue, 3 Jul 90 10:53:35 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 3 Jul 90 02:57:47 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
-In article <[e-mail]> From: [e-mail] (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 87

shar.1003.1.d.8224
echo 1003.1.e
cat >1003.1.e <<'shar.1003.1.e.8224'
From [e-mail]  Tue Jul  3 12:04:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10373; Tue, 3 Jul 90 12:04:29 -0400
Posted-Date: 3 Jul 90 04:44:27 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01829; Tue, 3 Jul 90 11:04:25 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23231; Tue, 3 Jul 90 10:56:54 cdt
From: Eric Schnoebelen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Summary: ANSI tape, tar, cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Central Iowa (Model) Railroad, Dallas, Tx.
Date: 3 Jul 90 04:44:27 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Eric Schnoebelen)

In article <[e-mail]> Peter da Silva writes:
- In article <[e-mail]> From: [e-mail] (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        [e-mail]        [e-mail]
    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 88

shar.1003.1.e.8224
echo 1003.1.f
cat >1003.1.f <<'shar.1003.1.f.8224'
From [e-mail]  Tue Jul  3 16:57:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16094; Tue, 3 Jul 90 16:57:30 -0400
Posted-Date: 3 Jul 90 18:18:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA25640; Tue, 3 Jul 90 15:53:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23963; Tue, 3 Jul 90 15:32:22 cdt
From: david paul hoyt <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jul 90 18:18:00 GMT
Apparently-To: [e-mail]

From:  david paul hoyt <[e-mail]>

>                                   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 | [e-mail] | dhoyt@umnacvx

Volume-Number: Volume 20, Number 89

shar.1003.1.f.8224
echo 1003.1.g
cat >1003.1.g <<'shar.1003.1.g.8224'
From [e-mail]  Wed Jul  4 00:20:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03843; Wed, 4 Jul 90 00:20:56 -0400
Posted-Date: 3 Jul 90 22:37:23 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21920; Tue, 3 Jul 90 23:20:54 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24870; Tue, 3 Jul 90 23:06:45 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jul 90 22:37:23 GMT
Apparently-To: [e-mail]

From:  [e-mail]

>From:  [e-mail] (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
                                          [e-mail]   utzoo!henry

Volume-Number: Volume 20, Number 91

shar.1003.1.g.8224
echo 1003.1.h
cat >1003.1.h <<'shar.1003.1.h.8224'
From [e-mail]  Wed Jul  4 12:27:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10176; Wed, 4 Jul 90 12:27:27 -0400
Posted-Date: 4 Jul 90 08:55:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA13158; Wed, 4 Jul 90 11:27:23 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00290; Mon, 4 Jun 90 11:19:24 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tsa.co.uk![e-mail]
Organization: The Standard Answer Ltd.
Date: 4 Jul 90 08:55:34 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

In article <[e-mail]> [e-mail] (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 <[e-mail]>,
> 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

shar.1003.1.h.8224
echo 1003.1.i
cat >1003.1.i <<'shar.1003.1.i.8224'
From [e-mail]  Thu Jul  5 17:50:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29638; Thu, 5 Jul 90 17:50:49 -0400
Posted-Date: 5 Jul 90 03:40:11 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07699; Thu, 5 Jul 90 16:50:46 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04772; Thu, 5 Jul 90 16:01:15 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 5 Jul 90 03:40:11 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> uunet!tsa.co.uk![e-mail] 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

shar.1003.1.i.8224
echo 1003.1.j
cat >1003.1.j <<'shar.1003.1.j.8224'
From [e-mail]  Thu Jul  5 17:51:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29697; Thu, 5 Jul 90 17:51:04 -0400
Posted-Date: 4 Jul 90 11:57:02 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07720; Thu, 5 Jul 90 16:51:02 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04885; Thu, 5 Jul 90 16:05:15 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 4 Jul 90 11:57:02 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] 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.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 99

shar.1003.1.j.8224
echo 1003.1.k
cat >1003.1.k <<'shar.1003.1.k.8224'
From [e-mail]  Tue Jul 10 03:35:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13267; Tue, 10 Jul 90 03:35:27 -0400
Posted-Date: 9 Jul 90 17:50:35 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01413; Tue, 10 Jul 90 02:35:23 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16541; Tue, 10 Jul 90 02:29:35 cdt
From: John Zolnowsky ext. 33230 <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Summary: _POSIX_n_SOURCE, a source of confusion?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Sun Microsystems, Inc. - Mtn View, CA
Date: 9 Jul 90 17:50:35 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John Zolnowsky ext. 33230)

In article <[e-mail]>, [e-mail] writes:
> Paul Rabin <[e-mail]> 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         [e-mail]              [phone]

Volume-Number: Volume 20, Number 117

shar.1003.1.k.8224
echo 1003.1.l
cat >1003.1.l <<'shar.1003.1.l.8224'
From [e-mail]  Thu Jul 12 08:13:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07313; Thu, 12 Jul 90 08:13:12 -0400
Posted-Date: 10 Jul 90 15:13:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19054; Wed, 11 Jul 90 19:30:10 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19012; Wed, 11 Jul 90 17:41:57 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 10 Jul 90 15:13:29 GMT
Apparently-To: [e-mail]

From:  Jason Zions <[e-mail]>

> 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

shar.1003.1.l.8224
echo 1003.1.m
cat >1003.1.m <<'shar.1003.1.m.8224'
From [e-mail]  Fri Jul 13 02:24:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15244; Fri, 13 Jul 90 02:24:58 -0400
Posted-Date: 12 Jul 90 03:27:28 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21731; Fri, 13 Jul 90 00:34:40 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20104; Thu, 12 Jul 90 20:17:08 cdt
From: John Michael Sovereign <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Apple Computer
Date: 12 Jul 90 03:27:28 GMT
Apparently-To: [e-mail]

From:  [e-mail] (John Michael Sovereign)


In article <[e-mail]> [e-mail] (Jason Zions) writes:

> 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.

There is, however, a single C language name space which new standards (and
revisions)
pollute as long as they continue to use header files already defined by
ANSI C and/or POSIX.1
(as I believe Doug Gwyn pointed out recently).

> The various 1003.* working groups are *not* developing separate
components
> of an overall, integrated POSIX standard. Each POSIX standard stands
alone....

>From what I've heard, there HAS been discussion at the ISO level of
bundling the C language
interfaces of POSIX.2 and/or POSIX.4 into future versions of 9945-1.
Unfortunately, a decision on this matter might be delayed until after the
IEEE standards have been adopted....

As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing
_POSIX_SOURCE
can't be used (perhaps modified) for this purpose.

John Sovereign
[e-mail]
"Perhaps software developers should face the same legal support
requirements as parents."


Volume-Number: Volume 20, Number 121

shar.1003.1.m.8224
echo 1003.1.n
cat >1003.1.n <<'shar.1003.1.n.8224'
From [e-mail]  Fri Jul 13 11:07:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25188; Fri, 13 Jul 90 11:07:05 -0400
Posted-Date: 11 Jul 90 21:33:56 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21771; Fri, 13 Jul 90 00:34:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20123; Thu, 12 Jul 90 20:17:56 cdt
From: Dave Decot <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Cupertino
Date: 11 Jul 90 21:33:56 GMT
Apparently-To: [e-mail]

From:  [e-mail] (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

shar.1003.1.n.8224
echo 1003.1.o
cat >1003.1.o <<'shar.1003.1.o.8224'
From [e-mail]  Sat Jul 14 04:48:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05485; Sat, 14 Jul 90 04:48:29 -0400
Posted-Date: 13 Jul 90 21:07:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14426; Sat, 14 Jul 90 01:05:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21275; Fri, 13 Jul 90 23:54:37 cdt
From: <mindcrf![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Summary: Say NO to feature test macro proliferation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Mindcraft, Inc.
Date: 13 Jul 90 21:07:17 GMT
Apparently-To: [e-mail]

From:  [e-mail]


In article <[e-mail]> [e-mail] writes:
>From:  [e-mail] (John Michael Sovereign)
>In article <[e-mail]> [e-mail] (Jason Zions) writes:
>
>> 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.
>
>There is, however, a single C language name space which new standards (and
>revisions)
>pollute as long as they continue to use header files already defined by
>ANSI C and/or POSIX.1
>(as I believe Doug Gwyn pointed out recently).

>From the 1003.1 standard, 2.8.2:

    Symbols called `feature test macros' are used to control the
    visibility of symbols that might be included in a header.
    Implementations, future versions of this standard, and other
    standards may define additional feature test macros.

My interpretation of this text is that the 1003.1 committee wanted to
provide a mechanism by which a number of standards and implementations
could share the C namespace.  Of course, extended use of this mechanism
is up to the other standards committees and implementors, and is
outside the scope of 1003.1.  Perhaps this is an issue that Dot 0
could help clear up.

>> The various 1003.* working groups are *not* developing separate
>components
>> of an overall, integrated POSIX standard. Each POSIX standard stands
>alone....

Which makes it essential that each standard specify what it assumes
is available from its host, and what it will add to the composite
environment.  While each standard may stand alone, implementations
certainly won't.

>As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing
>_POSIX_SOURCE
>can't be used (perhaps modified) for this purpose.

Because, unlike __STDC__, _POSIX_SOURCE is #defined or not #defined;
its value is not significant.  The implication of the suggestion to use
_POSIX_1_SOURCE for 1003.1a-conforming headers is that the 1003.1
committee is reserving for its own use all feature test macro names
that start with _POSIX_.  This means that the 1003.2 committee will be
on shaky ground if they require that programmers #define
_POSIX_2_SOURCE in order to make 1003.2 symbols visible.

The approach chosen by the ANSI C committee was a good one:  Use a single
name for the feature test macro, and change the macro's VALUE when a
new version of the standard supersedes an old one.
--

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


Volume-Number: Volume 20, Number 124

shar.1003.1.o.8224
echo 1003.1.p
cat >1003.1.p <<'shar.1003.1.p.8224'
From [e-mail]  Sat Jul 14 04:39:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03158; Sat, 14 Jul 90 04:39:39 -0400
Posted-Date: 12 Jul 90 23:23:25 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14484; Sat, 14 Jul 90 01:06:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21293; Fri, 13 Jul 90 23:55:25 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: FZI Forschungszentrum Informatik, Karlsruhe, West-Germany
Date: 12 Jul 90 23:23:25 GMT
Apparently-To: [e-mail]

From:  [e-mail]

--- archives and tapes ---

First, I have to admit that I haven't read the latest standard's version,
but I do have strong feelings about data archives and transport.

Both tar and cpio are highly deficient for properly moving information
out and in. The first blunder of all is the limited format that does not
take care of long file names. There is a NAMSIZ parameter, so for heaven's
sake reserve sufficient space in the file descriptor of such a transport
archive! That's so fundamental that I will only talk about one other equally
nasty point about these formats, missing archive and volume labelling.

Next, you have to realize that both tar and cpio already do arrange data
in suitable chunks for transfer ('tar' reads 'tape archive'!). There is
no reason in the world why an ANSI tape file shall not be the envelope
for a UNIX-type archive. On the contrary, this will finally, after all
these years offer data labelling, both on the archive and on the tape
volumes. It is unbelievable that today, 1990, i have to look at a piece of
paper with my tar tape, which tells me about a number of archives on the
same medium and their position. Additionally, the ANSI tar standard
provides multi-volume data sets, so yet another stumbling stone can be
forgotten, if we only wrap tar' and cpio' archives in ANSI tape structures
(where tar' and cpio' are improved versions of tar and cpio).

Then, a point often forgotten: There is a real need to select, duplicate,
store data from some external medium (tape) on a different type of machine
than the one the tape is written on / to be read.  The proposal above will
make that an easy and safe operation, what cannot be claimed today. (Today,
ypou just have to have a guru around who knows alls kinds of different
machines and how they mix).

Finally: Yes, we do move archives across networks, but for most substantial
transfers of data in and out of our machines there is no adequate replacement
for sequential magnetic media. Posix has to take that into account, or we
will be burdened with those problems of today.

Karl Kleine
FZI Forschungszentrum Informatik, Karlsruhe, West-Germany;  [e-mail]



Volume-Number: Volume 20, Number 125

shar.1003.1.p.8224
echo 1003.1.q
cat >1003.1.q <<'shar.1003.1.q.8224'
From [e-mail]  Sat Jul 14 04:26:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29533; Sat, 14 Jul 90 04:26:51 -0400
Posted-Date: 12 Jul 90 21:07:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14553; Sat, 14 Jul 90 01:06:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21312; Fri, 13 Jul 90 23:56:04 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 12 Jul 90 21:07:17 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>From:  Jason Zions <[e-mail]>
>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

shar.1003.1.q.8224
echo 1003.1.r
cat >1003.1.r <<'shar.1003.1.r.8224'
From [e-mail]  Sun Jul 15 19:33:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08081; Sun, 15 Jul 90 19:33:52 -0400
Posted-Date: 14 Jul 90 23:27:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00999; Sun, 15 Jul 90 18:33:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22977; Sun, 15 Jul 90 16:55:13 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 14 Jul 90 23:27:34 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)


>Then, a point often forgotten: There is a real need to select, duplicate,
>store data from some external medium (tape) on a different type of machine
>than the one the tape is written on / to be read.  The proposal above will
>make that an easy and safe operation,

Really?  The proposal above will deal with moving stuff from a machine
with a QIC-150-type 1/4" tape drive that can't write QIC-24 tapes to a
machine with a QIC-24-type 1/4" tape drive that can't read QIC-150 or
QIC-120 tapes?  Neat trick!

>what cannot be claimed today. (Today, ypou just have to have a guru
>around who knows alls kinds of different machines and how they mix).

"The proposal above" seems to be "put a 'tar' or 'cpio' archive as one
file within an ANSI-labelled tape."  I fail to see how that makes things
any better; if the problems are with variations between "cpio" and "tar"
formats on different machines, wrapping ANSI labels around the "tar" or
"cpio" data doesn't seem to make things any better.

If the *real* fix is in the "tar'" and "cpio'" formats you list, what do
the ANSI labels buy you other than multi-volume support?

>Finally: Yes, we do move archives across networks, but for most substantial
>transfers of data in and out of our machines there is no adequate replacement
>for sequential magnetic media.

By "data" do you mean "data as opposed to programs"?  If not, do any of
the folks who have retrieved, say, the X11 source via FTP or UUCP have
any comments on the above claim? I sucked the entire X11R3 distribution
to our site via UUCP; I would have done the same with the X11R4 format,
except that somebody already had it and offered to put it on 1/4" tapes
- fortunately, a 1/4" format we can read; they put it on a "tar" tape,
though, so ANSI tape labels contributed nothing....

I suspect the amount of software moved into our site via UUCP is at
least a significant fraction of the amount of software moved into our
site via magtapes.


Volume-Number: Volume 20, Number 128

shar.1003.1.r.8224
echo 1003.1.s
cat >1003.1.s <<'shar.1003.1.s.8224'
From [e-mail]  Sun Jul 15 19:34:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08257; Sun, 15 Jul 90 19:34:10 -0400
Posted-Date: 14 Jul 90 19:15:16 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01022; Sun, 15 Jul 90 18:34:08 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23015; Sun, 15 Jul 90 16:56:30 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 14 Jul 90 19:15:16 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>From:  [e-mail] (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

shar.1003.1.s.8224
echo 1003.1.t
cat >1003.1.t <<'shar.1003.1.t.8224'
From [e-mail]  Sun Jul 15 19:34:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08568; Sun, 15 Jul 90 19:34:46 -0400
Posted-Date: 14 Jul 90 19:37:46 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01044; Sun, 15 Jul 90 18:34:43 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23035; Sun, 15 Jul 90 16:57:08 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 14 Jul 90 19:37:46 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>>From the 1003.1 standard, 2.8.2:
>    Symbols called `feature test macros' are used to control the
>    visibility of symbols that might be included in a header.
>    Implementations, future versions of this standard, and other
>    standards may define additional feature test macros.
>My interpretation of this text is that the 1003.1 committee wanted to
>provide a mechanism by which a number of standards and implementations
>could share the C namespace.

The feature-test macro provision was the outcome of discussions among
DOnn Terry, Dave Prosser, myself, and a few others in an attempt to
resolve the problem that a single implementation could not simultaneously
conform to IEEE Std 1003.1 and ANS X3.159 due to the strict prohibition
of the latter against implementations defining or declaring non-reserved
identifiers in the standard headers.  Because of the evolutionary history
of the standard headers, some of them contained both UNIX-specific and
OS-independent definitions/declarations; for example, <stdio.h> included
fopen(), which applies in every hosted C environment, and fdopen(), which
is relevant only for UNIX-like environments.  Partly out of legitimate
political concerns, X3J11 refused to allow any special dispensation for
UNIX-specific extensions in the standard C headers, and as a generally
appreciated service to C programmers everywhere forbid conforming C
implementations to add other (non-reserved, i.e. not starting with
underscore etc.) identifiers to the standard headers.  Thus, in effect
other standards such as POSIX, if they are to be compatible with the C
language standard, must not require implementations to define/declare
such names in the headers specified in X3.159.  Yet, P1003 wished to add
some of the traditional UNIX identifiers to those headers.  This is the
problem that the feature-test macro POSIX_SOURCE was intended to solve.
(X3J11 recommended a similar but functionally different solution.)  While
they were at it, P1003 decided that packages other than 1003.1 might also
benefit from feature-test macros, and ended up with the wording you saw.

The technical loophole is that any application that defines _POSIX_SOURCE
has violated a constraint of X3.159, by using a reserved identifier, and
this allows the implementation to act in a non-X3.159-conforming manner,
in this case to define/declare otherwise-prohibited identifiers.

One drawback is that any portable 1003.1-based application that uses any
of the 1003.1 extensions in standard headers will have to predefine the
feature-test macro before including the headers.

There is no such problem with inclusion of headers NOT specified in
X3.159.  Thus, feature-test macros can be avoided simply by specifying
that new facilities be defined/declared in new add-on headers.  This is
much more convenient for the programmer and is highly recommended.
There is no historical-evolutionary problem for new POSIX standards,
and thus there is no need for a mechanism to share the standard headers
for new standards.  Instead of trying to add more cruft to standard C
headers, new inventions should provide their own headers.


Volume-Number: Volume 20, Number 131

shar.1003.1.t.8224
echo 1003.1.u
cat >1003.1.u <<'shar.1003.1.u.8224'
From [e-mail]  Thu Jul 19 01:53:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23037; Thu, 19 Jul 90 01:53:22 -0400
Posted-Date: 17 Jul 90 18:23:12 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15840; Thu, 19 Jul 90 00:53:17 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA26248; Wed, 18 Jul 90 23:13:29 cdt
From: Bob Lenk <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 17 Jul 90 18:23:12 GMT
Apparently-To: [e-mail]

From:  Bob Lenk <[e-mail]>

>The following features were deleted (but are still permitted):
>    CLK_TCK - non-existent definition imported from ANSI C standard

As of 1003.1a/D5 (also ISO/IEC DIS 9945-1.2), CLK_TCK is still required
to be defined in <time.h>.  It is obsolescent.  It is mentioned only
in one subclause (4.8.1.5), and is not used to define or describe any
other functionality.  Most features (such as times() are now described
in terms of "clock ticks".  Since it is no longer in the C Standard, it is
not mentioned in 2.7.1 (as in 1003.1-1988); the index seems to have an
erroneous reference to that deleted mention.

I don't know of any changes to this since that draft/DIS.

        Bob Lenk
        [e-mail]
        hplabs!hpfcla!rml


Volume-Number: Volume 20, Number 135

shar.1003.1.u.8224
echo 1003.2.a
cat >1003.2.a <<'shar.1003.2.a.8224'
From [e-mail]  Fri Jun 22 13:51:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08050; Fri, 22 Jun 90 13:51:38 -0400
Posted-Date: 22 Jun 90 00:21:27 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA22292; Fri, 22 Jun 90 12:51:34 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20745; Fri, 22 Jun 90 12:39:46 cdt
From: <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 22 Jun 90 00:21:27 GMT
Apparently-To: [e-mail]

From:  [e-mail]

In article <[e-mail]> [e-mail] writes:
>   getopt()  This functional interface provides a standard utility
>             argument parser that enforces the ``standard utility
>             syntax'' guidelines and might be used to implement the
>             getopts utility from POSIX.2.

Might it not be time to "push the envelope" as 1003.4 has done, and specify
Eric Allman's far superior "parseargs" interface? Getopt really doesn't do
that much: a command line parser using getopt is only slightly simpler than
one assembled completely out of a nested loop, and it doesn't do anything
to help generate usage messages and the like... with the result that usage
messages that are out of date are not that uncommon, even in system programs.

Parseargs also helps by providing a system-independent interface, more so
if you use my extended version of the unix driver routine. That way folks
who work in other environments will be encouraged to produce programs that
follow the P1003.2 interface when compiled under POSIX... and POSIX programs
will fit well into VAX/VMS, MS-DOS, etc...
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 37

shar.1003.2.a.8224
echo 1003.2.b
cat >1003.2.b <<'shar.1003.2.b.8224'
From [e-mail]  Sat Jun 23 09:04:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09404; Sat, 23 Jun 90 09:04:34 -0400
Posted-Date: 23 Jun 90 00:03:08 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12273; Sat, 23 Jun 90 08:04:31 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23600; Sat, 23 Jun 90 06:34:45 cdt
From: David J. MacKenzie <[e-mail]>
Newsgroups: comp.std.unix
Subject: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Maryland
Date: 23 Jun 90 00:03:08 GMT
Apparently-To: [e-mail]

From: David J. MacKenzie <[e-mail]>

> From:  [e-mail]

> Might it not be time to "push the envelope" as 1003.4 has done, and specify
> Eric Allman's far superior "parseargs" interface? Getopt really doesn't do
> that much: a command line parser using getopt is only slightly simpler than
> one assembled completely out of a nested loop, and it doesn't do anything
> to help generate usage messages and the like... with the result that usage
> messages that are out of date are not that uncommon, even in system programs.

> Parseargs also helps by providing a system-independent interface, more so
> if you use my extended version of the unix driver routine. That way folks
> who work in other environments will be encouraged to produce programs that
> follow the P1003.2 interface when compiled under POSIX... and POSIX programs
> will fit well into VAX/VMS, MS-DOS, etc...

Parseargs has a lot of problems; I looked at it and discarded it.  It
might provide a superior interface to the programmer, but it doesn't
provide the same interface to the user; that is, it doesn't conform to
the standard Unix option syntax that most programs use (allowing
ganging of multiple single-letter options into a single argument, for
example).  Since getopt is an existing-practice de-facto standard, I
see no justification for trying to push something quite different that
hardly anyone uses as an IEEE standard.  I don't think what 1003.4 is
doing is necessarily a good idea either.  It probably exceeds the
POSIX charter.
--
David J. MacKenzie <[e-mail]> <[e-mail]>

Volume-Number: Volume 20, Number 39

shar.1003.2.b.8224
echo 1003.2.c
cat >1003.2.c <<'shar.1003.2.c.8224'
From [e-mail]  Sat Jun 23 09:04:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09487; Sat, 23 Jun 90 09:04:53 -0400
Posted-Date: 23 Jun 90 05:54:31 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12308; Sat, 23 Jun 90 08:04:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23749; Sat, 23 Jun 90 06:43:39 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 23 Jun 90 05:54:31 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>Might it not be time to "push the envelope" as 1003.4 has done, and specify
>Eric Allman's far superior "parseargs" interface?

There have actually been MANY such inventions; however, getopt() is the
de facto standard in this area, and thus is appropriate for standardization.

Volume-Number: Volume 20, Number 41

shar.1003.2.c.8224
echo 1003.2.d
cat >1003.2.d <<'shar.1003.2.d.8224'
From [e-mail]  Wed Jun 27 03:41:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06881; Wed, 27 Jun 90 03:41:58 -0400
Posted-Date: 23 Jun 90 19:27:43 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25125; Wed, 27 Jun 90 02:41:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29691; Tue, 26 Jun 90 17:19:35 cdt
From: D'Arcy J.M. Cain <druid![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: druid![e-mail] (D'Arcy J.M. Cain)
Organization: D'Arcy Cain Consulting, West Hill, Ontario
Date: 23 Jun 90 19:27:43 GMT
Apparently-To: [e-mail]

From:  [e-mail] (D'Arcy J.M. Cain)

In article <[e-mail]> From: David J. MacKenzie <[e-mail]>
>Parseargs has a lot of problems; I looked at it and discarded it.  It
>might provide a superior interface to the programmer, but it doesn't
>provide the same interface to the user; that is, it doesn't conform to
>the standard Unix option syntax that most programs use (allowing
>ganging of multiple single-letter options into a single argument, for
>example).  Since getopt is an existing-practice de-facto standard, I

You might like my getarg function.  I designed it as a replacement for
getopt but in such a way that the user can use it exactly like getopt.
It does however support extra functionality which can be used if the user
is aware of it.  For one thing, options and arguments (files) can be
mixed instead of requiring all options to precede the files.  You can
also initialise the argument list more than once supporting things such
as environment default command lines, arguments from files etc mixed
with arguments from the command line.  I just posted it recently to
alt.sources and I'm interested in getting some feedback on it.

--
D'Arcy J.M. Cain (darcy@druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
[phone]                     |

Volume-Number: Volume 20, Number 45

shar.1003.2.d.8224
echo 1003.2.e
cat >1003.2.e <<'shar.1003.2.e.8224'
From [e-mail]  Wed Jun 27 03:44:00 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07360; Wed, 27 Jun 90 03:44:00 -0400
Posted-Date: 24 Jun 90 20:20:50 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25226; Wed, 27 Jun 90 02:43:55 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA29990; Tue, 26 Jun 90 17:42:09 cdt
From: <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 24 Jun 90 20:20:50 GMT
Apparently-To: [e-mail]

From:  [e-mail]

In article <[e-mail]> From: David J. MacKenzie <[e-mail]>
> Parseargs has a lot of problems; I looked at it and discarded it.

On the other hand, I looked at it and fixed them. Check comp.sources.misc.

> It
> might provide a superior interface to the programmer, but it doesn't
> provide the same interface to the user; that is, it doesn't conform to
> the standard Unix option syntax that most programs use (allowing
> ganging of multiple single-letter options into a single argument, for
> example).

Actually, it does do this. You shoulda looked harder. What it doesn't do
is handle variable nubers of arguments, which is one thing I fixed.

> Since getopt is an existing-practice de-facto standard, I
> see no justification for trying to push something quite different that
> hardly anyone uses as an IEEE standard.

Given the things that have already gone in to POSIX, even the almighty
base (such as fgetpos, or banning silent truncation of long file names)
I think that's a bit of a quibble. Getopt pretty much has to stay, I
agree. But parseargs should be considered as a recommended alternative.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>


Volume-Number: Volume 20, Number 49

shar.1003.2.e.8224
echo 1003.2.f
cat >1003.2.f <<'shar.1003.2.f.8224'
From [e-mail]  Thu Jun 28 15:39:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08943; Thu, 28 Jun 90 15:39:10 -0400
Posted-Date: 27 Jun 90 12:41:55 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA13723; Thu, 28 Jun 90 14:39:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05245; Thu, 28 Jun 90 12:17:32 cdt
From: Chip Salzenberg <tct![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: ComDev/TCT, Sarasota, FL
Date: 27 Jun 90 12:41:55 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Chip Salzenberg)

According to [e-mail] (D'Arcy J.M. Cain):
>[Getarg] support[s] extra functionality which can be used if the user
>is aware of it.  For one thing, options and arguments (files) can be
>mixed instead of requiring all options to precede the files.

Consider:

    rm ./-a -b -c -d -e -f

With getopt, all five arguments are filenames.  With getarg, the first
argument is a filename and the rest are options.  This is a feature?
No thanks.

--
Chip Salzenberg at ComDev/TCT     <[e-mail]>, <uunet!ateng!tct!chip>

Volume-Number: Volume 20, Number 53

shar.1003.2.f.8224
echo 1003.2.g
cat >1003.2.g <<'shar.1003.2.g.8224'
From [e-mail]  Thu Jun 28 15:39:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08971; Thu, 28 Jun 90 15:39:19 -0400
Posted-Date: 27 Jun 90 15:32:10 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA13736; Thu, 28 Jun 90 14:39:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05324; Thu, 28 Jun 90 12:22:37 cdt
From: Leslie Giles <codex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Codex Corp., Canton MA
Date: 27 Jun 90 15:32:10 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Leslie Giles)

[e-mail] (D'Arcy J.M. Cain) writes:

>You might like my getarg function.  I designed it as a replacement for
>   ... You can
>also initialise the argument list more than once supporting things such
>as environment default command lines, arguments from files etc mixed
>with arguments from the command line.  I just posted it recently to
>alt.sources and I'm interested in getting some feedback on it.

It is also possible to restart getopt() by setting various variables.
I did this in some code to support defaults, as mentioned above.  If anybody
wants to know how to do this then you can mail me (I don't have the code in
front of me at the moment - it'd take time to find it) at...

codex!lezz

Volume-Number: Volume 20, Number 54

shar.1003.2.g.8224
echo 1003.2.h
cat >1003.2.h <<'shar.1003.2.h.8224'
From [e-mail]  Sat Jun 30 15:01:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13140; Sat, 30 Jun 90 15:01:52 -0400
Posted-Date: 29 Jun 90 14:07:42 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA24409; Sat, 30 Jun 90 11:18:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA13336; Sat, 30 Jun 90 10:31:00 cdt
From: D'Arcy J.M. Cain <druid![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: parseargs vs. getopt
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: druid![e-mail] (D'Arcy J.M. Cain)
Organization: D'Arcy Cain Consulting, West Hill, Ontario
Date: 29 Jun 90 14:07:42 GMT
Apparently-To: [e-mail]

From:  [e-mail] (D'Arcy J.M. Cain)

In article <[e-mail]> [e-mail] writes:
>From:  [e-mail] (Leslie Giles)
>[e-mail] (D'Arcy J.M. Cain) writes:
>>   ... You can
>>also initialise the argument list more than once supporting things such
>>as environment default command lines, arguments from files etc mixed
>>with arguments from the command line.  I just posted it recently to
>>alt.sources and I'm interested in getting some feedback on it.
>
>It is also possible to restart getopt() by setting various variables.
>I did this in some code to support defaults, as mentioned above.  If anybody
>wants to know how to do this then you can mail me (I don't have the code in
>front of me at the moment - it'd take time to find it) at...
>
I guess I wasn't clear in that paragraph.  The posting goes into great detail
about this but the main point is not that you can restart your argument
processing but that another set of arguments can be stuffed into the ones
you already have.  It allows for something like the following:  Say you
have a program called foo which takes options a & b with no arguments and
f with an argument "on" or "off".  Perhaps the user normally wants this flag
off but wants to override that default this time.  Also the a flag is always
used.  The .profile has the following line:

foo="-a -f off"

Assume also that there is a file called bar with the following line:

-b

then he calls the program like this:

foo -f on -@ bar file1 -f off file2

Assuming that the program is set up correctly then the effective command
is

foo -a -f off -f on -b file1 -f off file2

Which should process file1 with the flag turned on and file2 with the flag
turned off.  As you can see, The environment variable is stuffed into the
command line between the program name and the first argument and the contents
of the file bar is inserted in the line where the file name appears.  While
it may be possible to do something like that with getopt I imagine it would
not be as simple as with my interface.

--
D'Arcy J.M. Cain (darcy@druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
[phone]                     |

Note to moderator:  I think this is the wrong group to discuss but I can't
decide the proper one.  Please feel free to add a followup-to line if you
wish.

[ I don't know a better place for it, either. -mod ]

Volume-Number: Volume 20, Number 73

shar.1003.2.h.8224
echo 1003.5.a
cat >1003.5.a <<'shar.1003.5.a.8224'
From [e-mail]  Sat Jun 23 09:05:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09546; Sat, 23 Jun 90 09:05:02 -0400
Posted-Date: 23 Jun 90 05:58:43 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA12327; Sat, 23 Jun 90 08:04:58 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA23805; Sat, 23 Jun 90 06:45:31 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 23 Jun 90 05:58:43 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

-The most detailed discussion involved whether or not files should be
-closed on an Exec.  The Ada binding provides a Start_Process function,
-which is a primitive that safely creates a new process.  In the face
-of Ada tasking, Fork and Exec are unsafe and cannot be used to
-accomplish the results of a Start_Process call.  Once one of these
-unsafe primitives is issued, an application program is no longer under
-the control of the Ada run time system; the operating system is
-involved. ...

Correct me if I'm mistaken, but I thought the specific task of
1003.5 was to provide Ada-language bindings to 1003.1, not to
add functionality.

Volume-Number: Volume 20, Number 42

shar.1003.5.a.8224
echo 1003.5.b
cat >1003.5.b <<'shar.1003.5.b.8224'
From [e-mail]  Wed Jun 27 03:44:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07398; Wed, 27 Jun 90 03:44:15 -0400
Posted-Date: 24 Jun 90 01:47:10 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA25256; Wed, 27 Jun 90 02:44:11 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00077; Tue, 26 Jun 90 17:51:35 cdt
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]>;
Sender: [e-mail]
Reply-To: [e-mail]
Date: 24 Jun 90 01:47:10 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Shane McCarron)

> From:  Doug Gwyn <[e-mail]>
>
> Correct me if I'm mistaken, but I thought the specific task of
> 1003.5 was to provide Ada-language bindings to 1003.1, not to
> add functionality.

Remember the history of POSIX.1.  We have a standard which should have
been specified in a language independent manner.  If that had been
done, a number of the functions that are in the standard would not be
there, or would be in the C bindings section.  They are convenience
functions for C.  Likewise, there will be convenience functions for
other languages.  Ada is particularly nasty, for all the obvious
reasons.

Someday there will be a language independent 1003.1 specification.  It
will detail the real functionality of the underlying system in such a
way that it will be clear to people doing language bindings which
features they must include.  Until then, there will continue to be
confusion on the subject.

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]

Volume-Number: Volume 20, Number 50

shar.1003.5.b.8224
echo 1003.5.c
cat >1003.5.c <<'shar.1003.5.c.8224'
From [e-mail]  Wed Jun 27 16:55:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03432; Wed, 27 Jun 90 16:55:34 -0400
Posted-Date: 27 Jun 90 12:14:08 GMT
Received: by cs.utexas.edu (5.64/1.64)
    id AA26591; Wed, 27 Jun 90 15:55:27 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01608; Wed, 27 Jun 90 13:41:04 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 27 Jun 90 12:14:08 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From: [e-mail] (Shane McCarron)
>Remember the history of POSIX.1.  We have a standard which should have
>been specified in a language independent manner.  If that had been
>done, a number of the functions that are in the standard would not be
>there, or would be in the C bindings section.  They are convenience
>functions for C.  Likewise, there will be convenience functions for
>other languages.  Ada is particularly nasty, for all the obvious
>reasons.

I DO remember the history of 1003.1; I was there!  We most certainly
did NOT set out to create a language-independent standard; C was
specifically chosen for the obvious reason that it was the SOLE
appropriate language for systems-level programming on UNIX, for a
variety of reasons, including the fact that the UNIX kernel has a
marked preference for being fed C data types.

This "language binding" nonsense was foisted off on P1003 in an
attempt to meet ISO guidelines.  I think it must have been adopted
by ISO as the result of Pascal types insisting that they never have
to use any other language.

Clearly, a BASIC, COBOL, or even LISP binding to 1003.1 would be
ludicrous.  I don't know how languages are selected for binding,
but I do know what constitutes a UNIX system interface, and if a
language can support one then that is what it should be given as a
1003.1 binding.

Volume-Number: Volume 20, Number 51

shar.1003.5.c.8224
echo 1003.5.d
cat >1003.5.d <<'shar.1003.5.d.8224'
From [e-mail]  Thu Jun 28 18:17:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25268; Thu, 28 Jun 90 18:17:38 -0400
Posted-Date: 28 Jun 90 16:12:39 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA25997; Thu, 28 Jun 90 17:17:33 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06921; Thu, 28 Jun 90 16:43:23 cdt
From: Loren Buck Buchanan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center
Date: 28 Jun 90 16:12:39 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Loren (Buck) Buchanan)

In article <[e-mail]> From:  Doug Gwyn <[e-mail]>
>I DO remember the history of 1003.1; I was there!  We most certainly
>did NOT set out to create a language-independent standard; C was
>specifically chosen for the obvious reason that it was the SOLE
>appropriate language for systems-level programming on UNIX, for a
>variety of reasons, including the fact that the UNIX kernel has a
>marked preference for being fed C data types.

Sometimes you have to make painful changes, so that the future
generations will not have to suffer with "historical artifacts".
This is one place I think the changes should have been made (but
of course I do not know all of the argumentation, compromises, etc.
that passed before the committee came to an agreement.

>This "language binding" nonsense was foisted off on P1003 in an
>attempt to meet ISO guidelines.  I think it must have been adopted
>by ISO as the result of Pascal types insisting that they never have
>to use any other language.

I take exception to "nonsense was foisted".  The reason for language
bindings is so that various different languages can take advantage
of the standard.  Why should PASCALers, FORTRANers, etc. be coerced
into giving up their favorite language.  I regularly use three
different langauges, and I expect that the operating environment I
am working under will not impede my use of these languages.

>Clearly, a BASIC, COBOL, or even LISP binding to 1003.1 would be
>ludicrous.  I don't know how languages are selected for binding,
>but I do know what constitutes a UNIX system interface, and if a
>language can support one then that is what it should be given as a
>1003.1 binding.

Why is it ludicrous,  I think all of them should have bindings to POSIX,
but don't ask me to do the work.  If POSIX is to become truly universal,
then it better support all of them and also RPG II/III, PL/I, Prolog,
MUMPS, and any other general or special purpose language that is in
common use.  How a language is selected is two part, 1) is there a
consensus of the committee that the work should be done, and 2) is
there a fool  ... eh ... er ... uh ... volunteer willing to do the
work of creating and/or being the editor.

I am currently working on the proposed image processing standard, and
how acceptable do you think this standard would be if we ignored
FORTRAN?

B Cing U

Buck

--
Loren Buchanan     | [e-mail]   | #include <std_disclaimer.h>
CSC, 1100 West St. | ...!ames!dftsrv!drax!buck | typedef int by
Laurel, MD 20707   | [phone]            | void where_prohibited(by law){}
CD International lists over 40,000 pop music CDs, collect the whole set.

Volume-Number: Volume 20, Number 57

shar.1003.5.d.8224
echo 1003.5.e
cat >1003.5.e <<'shar.1003.5.e.8224'
From [e-mail]  Sat Jun 30 01:21:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08940; Sat, 30 Jun 90 01:21:45 -0400
Posted-Date: 29 Jun 90 21:46:11 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05326; Sat, 30 Jun 90 00:21:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12500; Sat, 30 Jun 90 00:26:28 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 29 Jun 90 21:46:11 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From: [e-mail] (Loren Buchanan)
>Why should PASCALers, FORTRANers, etc. be coerced into giving up
>their favorite language.  I regularly use three different langauges,
>and I expect that the operating environment I am working under will
>not impede my use of these languages.

That's not what we're talking about.  Pascal and Fortran can be
fully implemented in a UNIX environment.  You are not being asked
to "give up" those languages.  What I am saying is that you should
not insist on using a language in an application domain for which
it is ill suited.  Fortran is not an appropriate choice for systems
programming applications in a UNIX environment.  While it is
perhaps possible to devise a complete 1003.1 binding for Fortran
(I suspect it wouldn't be possible for BASIC), there is no real need
to do so.  On the other end of the spectrum, Ada has its own notions
of tasking that don't mesh well with UNIX's process model.  Since
the promulgators of Ada have insisted for years that Ada programs
must not use extensions to the language, I suggest that holding them
to their word would have been quite appropriate.

Volume-Number: Volume 20, Number 71

shar.1003.5.e.8224
echo 1003.6.a
cat >1003.6.a <<'shar.1003.6.a.8224'
From [e-mail]  Sat Jun 30 01:21:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08761; Sat, 30 Jun 90 01:21:03 -0400
Posted-Date: 29 Jun 90 21:12:26 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05276; Sat, 30 Jun 90 00:20:58 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12252; Sat, 30 Jun 90 00:14:40 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 29 Jun 90 21:12:26 GMT
Apparently-To: [e-mail]

From:  Jason Zions <[e-mail]>

> Conversely, users at a high classification may not make their work
> available to users at a lower classification: one can neither ``read up''
> nor ``write down.'' There are also compartments within each
> classification level, such as NATO, nuclear, DOE, or project X.  Access
> requires the proper level and authorization for all compartments
> associated with the resource.  The MAC group is defining interfaces for
> such a mandatory mechanism.  It's not as confusing as it sounds, but
> outside of the DoD it is as useless as it sounds.  (Prove me wrong.  Show
> me how this DoD policy is useful in a commercial environment.)

Both compartmentalization and classification have commercial applications,
but I'm not certain those applications justify the cost and pain.

Compartmentalization: Large organizations frequently pursue strategies and
practices in the course of daily business that seem, well, contradictory.
Things like negotiating with arch-rival companies to sell each of them
exclusive rights to a particular technology; at some point, when the
higher-ups figure one of the two deals is superior, the other "falls
through". For the sake of verisimilitude, one might wish to
compartmentalize both negotiation efforts from each other and from the rest
of the company on a "need-to-know" basis.

One might wish to compartmentalize ones research labs from ones marketing
people to prevent the marketing of "futures"; similarly, separating R&D
from support organizations can help prevent leakage.

All of these can be accomplished by a Simple Matter Of Policy; it is a
known phenomena, though, that the large the company the higher the
probability of leakage, regardless of policy. MAC can help.

Classification: Certain kinds of information are frequently required by law
to be controlled with respect to dissemination internally; data related to
profit and loss, stock exchange filings, personnel data, etc. Many
companies today forbid the electronic storage of such restricted
information, and they distribute it by means of printed copies, numbered
and signed for, burn-before-reading. It'd be nice to be able to store that
stuff on-line, transmit it electronically, while ensuring that those who
are not permitted by law to see the information cannot see it.

Again, SMOP can accomplish this; however, it's a lot easier to prove
someone is or is not an "insider" in the technical sense of the term by
showing whether or not they hda access to the relevant data, and by
recourse to an audit trail.

 - - - -

> Jason Zions, of HP, gave one of the most interesting and aggressive
                                                           ^^^^^^^^^^
> presentations of the day, on the work of the Transparent File Access
> Group, which included a preliminary list of issues that 1003.8 feels
> need to be reviewed.

Really? (wince)  Musta been a bad day. My apologies to all.

Jason Zions
Chair, 1003.8

Volume-Number: Volume 20, Number 67

shar.1003.6.a.8224
echo 1003.6.b
cat >1003.6.b <<'shar.1003.6.b.8224'
From [e-mail]  Sat Jun 30 01:21:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08963; Sat, 30 Jun 90 01:21:55 -0400
Posted-Date: 29 Jun 90 19:40:47 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA05335; Sat, 30 Jun 90 00:21:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12558; Sat, 30 Jun 90 00:29:34 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 29 Jun 90 19:40:47 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From:  <[e-mail]> (anonymous 1003.6 report)
> At the ISO level, there will be no separate security standard. ...
> This means every conforming
> system will include security mechanisms.

You mean, "will include DoD-style security mechanisms". The somewhat
simple-minded approach UNIX has had in the past has been remarkably
successful, considering.

> I like this.  Do you?

Only if it's possible to turn everything off and go back to /etc/passwd
and /etc/shadow, and a superuser. That way when something goes wrong you'll
be able to boot from tape or floppy, edit a couple of files, and recover
the system.

Because something *will* go wrong.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 72

shar.1003.6.b.8224
echo 1003.6.c
cat >1003.6.c <<'shar.1003.6.c.8224'
From [e-mail]  Mon Jul  2 09:44:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25480; Mon, 2 Jul 90 09:44:27 -0400
Posted-Date: 2 Jul 90 07:01:49 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05110; Mon, 2 Jul 90 08:44:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19939; Mon, 2 Jul 90 08:32:11 cdt
From: Phil Ronzone <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: 2 Jul 90 07:01:49 GMT
Apparently-To: [e-mail]

From: [e-mail] (Phil Ronzone)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>You mean, "will include DoD-style security mechanisms". The somewhat
>simple-minded approach UNIX has had in the past has been remarkably
>successful, considering.

I'm not sure what the "DoD-style" words mean, but UNIX has been very deficient
for much serious commercial work due to the "simple-minded" approach it has
had.



>> I like this.  Do you?
>
>Only if it's possible to turn everything off and go back to /etc/passwd
>and /etc/shadow, and a superuser. That way when something goes wrong you'll
>be able to boot from tape or floppy, edit a couple of files, and recover
>the system.
>
>Because something *will* go wrong.

I don't see what this has to do with security.
--
<---------------------------------------------------------------------------->
Philip K. Ronzone                  S e c u r e   U N I X           [e-mail]
Silicon Graphics, Inc. MS 9U-500                           work [phone]
2011 N. Shoreline Blvd., Mountain View, CA 94039            fax [phone]

Volume-Number: Volume 20, Number 84

shar.1003.6.c.8224
echo 1003.6.d
cat >1003.6.d <<'shar.1003.6.d.8224'
From [e-mail]  Wed Jul  4 00:22:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04460; Wed, 4 Jul 90 00:22:09 -0400
Posted-Date: 3 Jul 90 18:16:09 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21970; Tue, 3 Jul 90 23:22:06 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA25115; Tue, 3 Jul 90 23:18:20 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 3 Jul 90 18:16:09 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From: [e-mail] (Phil Ronzone)
> I'm not sure what the "DoD-style" words mean, but UNIX has been very deficient
> for much serious commercial work due to the "simple-minded" approach it has
> had.

This may well be true. But for a large set of problems the existing UNIX
security approach is quite sufficient. If you don't have the actual hardware
secured it's overkill.

> >Only if it's possible to turn everything off and go back to /etc/passwd
> >and /etc/shadow, and a superuser. That way when something goes wrong you'll
> >be able to boot from tape or floppy, edit a couple of files, and recover
> >the system.

> >Because something *will* go wrong.

> I don't see what this has to do with security.

I know of at least one case where a hard error in the user database for
a system required sending a letter from the president of the user's
company to the vendor to get them to explain how to regain access to the
system. Security and convenience are opposed goals, and sometimes a system
MUST be available.

If *all* POSIX conformant systems come with a stronger security system than
UNIX installed, it must be possible to set things up so that security system
can be defeated and a new system set up with physical access to the hardware.
It's acceptable for there to be some magic one-way juju that you can do to
put the system into a highly secure state, but it should not come that way.
I will neither purchase nor recommend any system I can't get into and rebuild
the access system with a boot floppy and the console.
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 95

shar.1003.6.d.8224
echo 1003.6.e
cat >1003.6.e <<'shar.1003.6.e.8224'
From [e-mail]  Thu Jul  5 20:29:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12636; Thu, 5 Jul 90 20:29:55 -0400
Posted-Date: 5 Jul 90 19:25:49 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19602; Thu, 5 Jul 90 19:29:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05317; Thu, 5 Jul 90 18:48:27 cdt
From: Phil Ronzone <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: 5 Jul 90 19:25:49 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Phil Ronzone)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>This may well be true. But for a large set of problems the existing UNIX
>security approach is quite sufficient. If you don't have the actual hardware
>secured it's overkill.

I disagree - secure software, from the boot code on, is very effective.

>Security and convenience are opposed goals, and sometimes a system
>MUST be available.

I disagree again -- I think the recent Internet worm is an example of why.

--
<---------------------------------------------------------------------------->
Philip K. Ronzone                  S e c u r e   U N I X           [e-mail]
Silicon Graphics, Inc. MS 9U-500                           work [phone]
2011 N. Shoreline Blvd., Mountain View, CA 94039            fax [phone]





Volume-Number: Volume 20, Number 100

shar.1003.6.e.8224
echo 1003.6.f
cat >1003.6.f <<'shar.1003.6.f.8224'
From [e-mail]  Fri Jul  6 11:34:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12483; Fri, 6 Jul 90 11:34:06 -0400
Posted-Date: 6 Jul 90 06:58:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA24354; Fri, 6 Jul 90 10:34:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA07372; Fri, 6 Jul 90 10:21:05 cdt
From: Steven M. Schultz <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Steven M. Schultz)
Organization: Contel Federal Systems
Date: 6 Jul 90 06:58:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Steven M. Schultz)

In article <[e-mail]> From:  [e-mail] (Phil Ronzone)
>In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>>This may well be true. But for a large set of problems the existing UNIX
>>security approach is quite sufficient. If you don't have the actual hardware
>>secured it's overkill.
>
>I disagree - secure software, from the boot code on, is very effective.

    i have to side with Peter on this.  the keywords were "large set
    of problems" and "quite sufficient" - that doesn't (at least to
    me) obviate the need for more strict security when the need
    arises, but for many situations just administering the systems
    correctly is enough.

    short of soldiers with M16s at a computer facility door i do not
    believe that software is any substitute for physical security.
    it's just one more password that has to be spread around (in
    case the SSO or whoever) goes on vacation, etc...

>>Security and convenience are opposed goals, and sometimes a system
>>MUST be available.

    agreed.

>I disagree again -- I think the recent Internet worm is an example of why.

    now it's my turn to disagree.  sheesh, why does the worm have to
    be brought up everytime security is discussed?  it was a BUG that
    was exploited, and i for one do not think that adding security
    will do away with BUGs in software.  on the contrary, as the
    complexity of the system is increased by the added software the
    number of bugs could actually increase, no?

    and, if people can't administer systems "correctly" now - what's
    going to happen when the amount of administration required increases
    due to the files/databasei/etc that "security" will add to the system??

    Steven M. Schultz
    [e-mail]

Volume-Number: Volume 20, Number 104

shar.1003.6.f.8224
echo 1003.6.g
cat >1003.6.g <<'shar.1003.6.g.8224'
From [e-mail]  Fri Jul  6 20:57:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26863; Fri, 6 Jul 90 20:57:52 -0400
Posted-Date: 6 Jul 90 14:38:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05040; Fri, 6 Jul 90 19:57:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA09158; Fri, 6 Jul 90 19:51:42 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 6 Jul 90 14:38:32 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Phil Ronzone) writes:
> In article <[e-mail]> [e-mail] (Peter da Silva) writes:
> >This may well be true. But for a large set of problems the existing UNIX
> >security approach is quite sufficient. If you don't have the actual hardware
> >secured it's overkill.

> I disagree - secure software, from the boot code on, is very effective.

I'm sure it is. An SR71 is very effective, too, but I find a 747 a whole
lot more convenient for a trip to Hawaii.

> >Security and convenience are opposed goals, and sometimes a system
> >MUST be available.

> I disagree again -- I think the recent Internet worm is an example of why.

What do you disagree with? That security and convenience are opposed goals,
or that sometimes a system MUST be available? And why?

(what the internet worm has to do with anything is another question. There
 have been similar incidents on systems with tighter security requirements,
 such as the DECNET WANK incident or the CHRISTMAS TREE virus. For that matter
 I have laid out the preliminary design for a virus that can propogate via
 Usenet source archives. And from what I know of the internet worm it would
 have spread pretty near as fast if sendmail didn't run under root permissions.
 start with a non-sequiter and I guess you can prove anything)
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>


Volume-Number: Volume 20, Number 108

shar.1003.6.g.8224
echo 1003.6.h
cat >1003.6.h <<'shar.1003.6.h.8224'
From [e-mail]  Tue Jul 10 03:35:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13238; Tue, 10 Jul 90 03:35:16 -0400
Posted-Date: 9 Jul 90 06:22:37 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01402; Tue, 10 Jul 90 02:35:12 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16476; Tue, 10 Jul 90 02:24:15 cdt
From: Phil Ronzone <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: 9 Jul 90 06:22:37 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Phil Ronzone)

In article <[e-mail]> [e-mail] (Steven M. Schultz) writes:
>    short of soldiers with M16s at a computer facility door i do not
>    believe that software is any substitute for physical security.
>    it's just one more password that has to be spread around (in
>    case the SSO or whoever) goes on vacation, etc...

Argument of two different fruits here.

As an example, we purchased an AT&T 630 (386 PC type machine) to run
AT&T SV/MLS (B1 UNIX). We had AT&T put the software on, and they set,
as is required the passwords.

But they forgot to tell us what the passwords were. Although we had
physical possesion of the machine, in a company that also make computers,
it would have taken us a while to "boot" the system (i.e., insecurely).

And we would have been able to do that ONLY because of the fact that the
machine used standard disks with "standard" UNIX filesystems and so on.

Whereas the same hardware with normal UNIX would have very vulnerable.

A safe protects your money, but if a huge helicopter steals the safe
and you have weeks to work on it, you can open it.



>>I disagree again -- I think the recent Internet worm is an example of why.
>
>    now it's my turn to disagree.  sheesh, why does the worm have to
>    be brought up everytime security is discussed?  it was a BUG that
>    was exploited, and i for one do not think that adding security
>    will do away with BUGs in software.  on the contrary, as the

Eh? That's the WHOLE point of Orange book security and the TCB concept.
Those programs would have never made it into the TCB and been able to
propagate like they did. Although it is not the best example.

The answer was more to WHY would someone want security. Answer is, to
control what you have your system do.
--
<---------------------------------------------------------------------------->
Philip K. Ronzone                  S e c u r e   U N I X           [e-mail]
Silicon Graphics, Inc. MS 9U-500                           work [phone]
2011 N. Shoreline Blvd., Mountain View, CA 94039            fax [phone]

Volume-Number: Volume 20, Number 116

shar.1003.6.h.8224
echo 1003.6.i
cat >1003.6.i <<'shar.1003.6.i.8224'
From [e-mail]  Thu Jul 12 07:43:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01039; Thu, 12 Jul 90 07:43:04 -0400
Posted-Date: 10 Jul 90 15:43:41 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19065; Wed, 11 Jul 90 19:30:21 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA19031; Wed, 11 Jul 90 17:42:40 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 10 Jul 90 15:43:41 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Phil Ronzone) writes:
[had a B1 UNIX box]
> But they forgot to tell us what the passwords were. Although we had
> physical possesion of the machine, in a company that also make computers,
> it would have taken us a while to "boot" the system (i.e., insecurely).

And if you needed to use the machine, you would have been out of luck.

For some people that level of security has a negative value. It's that
simple. It's not like we're saying "we want all UNIX systems to be
insecure", we're saying "we don't want all UNIX systems to come with
that level of security". Can't you see the difference?
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>



Volume-Number: Volume 20, Number 120

shar.1003.6.i.8224
echo 1003.6.j
cat >1003.6.j <<'shar.1003.6.j.8224'
From [e-mail]  Sun Jul 15 19:34:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08198; Sun, 15 Jul 90 19:34:03 -0400
Posted-Date: 15 Jul 90 01:52:16 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01006; Sun, 15 Jul 90 18:34:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22997; Sun, 15 Jul 90 16:55:54 cdt
From: Sean Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Date: 15 Jul 90 01:52:16 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Sean Fagan)

In article <[e-mail]> [e-mail] writes:
>As an example, we purchased an AT&T 630 (386 PC type machine) to run
>AT&T SV/MLS (B1 UNIX). We had AT&T put the software on, and they set,
>as is required the passwords.
>
>Whereas the same hardware with normal UNIX would have very vulnerable.

Do you honestly believe that, short of encrypting the data on the disk,
sufficient security is going to keep your data "safe" if your machine is
(physicially) compromised?

Uh-huh.
--
-----------------+
Sean Eric Fagan  | "Just think, IBM and DEC in the same room,
[e-mail]    |      and we did it."
uunet!sco!seanf  |         -- Ken Thompson, quoted by Dennis Ritchie




Volume-Number: Volume 20, Number 129

shar.1003.6.j.8224
echo overview.a
cat >overview.a <<'shar.overview.a.8224'
From [e-mail]  Sun Jul  1 12:09:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10223; Sun, 1 Jul 90 12:09:41 -0400
Posted-Date: 1 Jul 90 06:38:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA17519; Sun, 1 Jul 90 11:09:38 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA16129; Sun, 1 Jul 90 11:18:40 cdt
From: Barry Margolin <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Date: 1 Jul 90 06:38:34 GMT
Apparently-To: [e-mail]

Moderator!:  Delete most of these lines (begin):
Return-Path: <[e-mail]>
Sender: uunet!Think.COM!news
Submitted-From: uunet!Think.COM!barmar (Barry Margolin)
Moderator!:  Delete most of these lines (end).

From:  [e-mail] (Barry Margolin)

In article <[e-mail]> From: <[e-mail]>
>  The problem being addressed is how to move all printable
>strings out of our programs and into external ``message'' files so
>that we can change program output from, say, English to German by
>changing an environmental variable.

Both examples you supplied were simply ways to look up strings to output in
a database keyed on locale and an internal program string; they differ only
in minor ways.  Does either proposal address any of the *hard* issues?  For
instance, different languages have different pluralization rules; how do
you internationalize a program that automatically pluralizes when necessary
(I hate programs that say things like "1 files deleted")?  Or what about
differing word order; how would you internationalize

    printf("the %s %s", adjective, noun);

so that it would look right in a language where adjectives follow nouns?
--
Barry Margolin, Thinking Machines Corp.

[e-mail]
{uunet,harvard}!think!barmar

Volume-Number: Volume 20, Number 77

shar.overview.a.8224
echo overview.b
cat >overview.b <<'shar.overview.b.8224'
From [e-mail]  Mon Jul  2 13:01:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14730; Mon, 2 Jul 90 13:01:47 -0400
Posted-Date: 2 Jul 90 15:27:15 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21614; Mon, 2 Jul 90 12:01:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20630; Mon, 2 Jul 90 11:53:36 cdt
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 2 Jul 90 15:27:15 GMT
Apparently-To: [e-mail]

From:  Jason Zions <[e-mail]>

Regarding the Snitch Editor's fine report, in the section discussing
1003.12 comes the following sentence:

> Our snitch, Andy Nicholson, challenged readers to find a reason not to
> make DNI endpoints POSIX file descriptors, but has seen no takers.

How about because it constrains implementations to make DNI
kernel-resident?

How about because the semantics of operations permitted on POSIX file
descriptors are a poor match for many transport providers? Read()/write()
are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
maps much more closely to stdio and fgets()/fputs() in that it is
record-oriented. What does it mean to seek() on a network endpoint?

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 squeemish about accusing
them of having only a hammer in their toolbelt; of *course* everything
looks like a nail!

I think it would probably be acceptable to have a DNI function which
accepted a DNI endpoint as argument and attempted to return a real file
descriptor. This function would check to see that the underlying transport
provider could present reasonable semantics through a POSIX file
descriptor, and would also check that the implementation supported access
to that transport provider through a kernel interface.

Jason Zions

*  UNIX is a trademark of AT&T in the US and other countries.
** Obstreperous iconoclast is a behavioral trademark of Jason Zions in the
   US and other countries.

Volume-Number: Volume 20, Number 85

shar.overview.b.8224
echo overview.c
cat >overview.c <<'shar.overview.c.8224'
From [e-mail]  Mon Jul  2 18:02:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05412; Mon, 2 Jul 90 18:02:05 -0400
Posted-Date: 2 Jul 90 20:24:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA16596; Mon, 2 Jul 90 17:02:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21729; Mon, 2 Jul 90 16:57:57 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 2 Jul 90 20:24:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>Both examples you supplied were simply ways to look up strings to output in
>a database keyed on locale and an internal program string; they differ only
>in minor ways.  Does either proposal address any of the *hard* issues?  For
>instance, different languages have different pluralization rules; how do
>you internationalize a program that automatically pluralizes when necessary
>(I hate programs that say things like "1 files deleted")?  Or what about
>differing word order; how would you internationalize
>
>    printf("the %s %s", adjective, noun);
>
>so that it would look right in a language where adjectives follow nouns?

The latter can addressed by a scheme like the X/Open NLS scheme, in
which "printf" arguments can be decorated by specifiers that say which
of the N arguments to "*printf" following the format string should be
used; the "the %s %s" would have to replace "%s %s" with "%$2s %$1s".

HOWEVER:

This does *NOT* do anything about the pluralization rules.  It *also*
does nothing about the fact that the correct translation of "the" could
depend on the noun in question; i.e., is it "la" or "le" in French?

I think that, for reasons such as these, the only solution to the
problem of trying to find a Magic Bullet so that you can trivially
internationalize the message-printing code of applications by throwing a
simple-minded wrapper around "printf" (whether the #define approach, or
replacing the format string with "getmsg(the format string)", or
whatever) is to have software that is sufficiently knowledgable about
*all* human languages supported that it knows the gender of all nouns
you'll use in your messages, and knows the right articles for those
genders (for all cases the language has), and knows how to pluralize
arbitrary words.

In fact, I'm not even sure *that's* sufficient; I only know about some
Indo-European languages, and other languages may throw in problems I
haven't even considered.

In other words, I don't think there's a solution to the problem of "oh
dear, how are we going to get all our applications modified to put out
grammatically-correct messages in different languages without having to
examine all the code that generates messages and possibly rewrite some
of that code" other than teaching the system a fair bit about lots of
human languages.  I don't think you can even come up with an approach
that's close enough to a solution to be interesting.  I'm afraid you're
just going to have to fall back on things such as:

    having "1 frob" and "%d frobs" be *two* separate messages in the
    message catalog;

    having "the chair" and "the table" either be two separate
    messages, rather than having "the %s" and foreign-language
    versions of same, or having the message be "%s %s" and have the
    database tie the noun and the article together (watch out for
    Russian, though, they don't *use* articles...);

etc..

Yeah, this may mean human intervention, rather than being able to
internationalize your messages by running just running a few programs
over the code; nobody ever said that life was fair.  Might as well bite
the bullet....

Volume-Number: Volume 20, Number 86

shar.overview.c.8224
echo overview.d
cat >overview.d <<'shar.overview.d.8224'
From [e-mail]  Wed Jul  4 00:20:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03827; Wed, 4 Jul 90 00:20:46 -0400
Posted-Date: 3 Jul 90 20:41:28 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21914; Tue, 3 Jul 90 23:20:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24803; Tue, 3 Jul 90 23:03:26 cdt
From: Kee Hinckley <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities [NLS stuff]
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: asi
Date: 3 Jul 90 20:41:28 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Kee Hinckley)

In article <[e-mail]> From: <[e-mail]>
>To help you think about the problem, here's the way you'll have to
>write the "hello, world" koan using the X/OPEN interfaces:
....
>          (void)setlocale(LC_ALL, "");
>          catd = catopen("hello", 0); /* error checking omitted for brevity */
>          printf(catgets(catd, 1, 1,"hello, world\n"));
....
>and using the alternative, proposed UniForum interfaces:
....
>          (void)setlocale(LC_ALL, "");
>          (void)textdomain("hello");
>          printf(gettext("hello, world\n"));
....
>I suppose if I had my druthers, I'd like to see a standard interface
>that goes even farther than the UniForum proposal: one that adds a
....
>          (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
>          printf("hello, world\n");
....
>but that would still be untested innovation.

First of all, I don't think that either of these add enough of value to the
X/Open standard to make it worthwhile for those of using it to switch.
The use of strings as an index into the catalog though is definitely a BAD IDA.

Why?  A number of reasons.  First of all it's ethnocentric.  You've just told
every Easterner/MiddleEasterner that the default language is English.  Secondly
it's inefficent to and a pain to implement.  Thirdly it can produce results
which are just plain wrong.  I have different places in my application where
the English string is currently the same.  Using these schemes it would always
look up the same item in the catalog.  However in a different language the
string might well be different, but there would be no way of changing it one place
and not the other.

BTW.  Where can I get a specification of the Uniforum proposal (and comment
on it)?

The complexity of the X/Open stuff is easily hidden on a per application basis.
Anytime I want to reference a string in my application all I have to say
is MC(foo), where foo is #defined appropriately.

Where I *do* see room for improvement is in the definition of the catalog
file itself.  There is currently no specification for generating include
files or anything else, and hand numbering the strings is a royal pain.

If you consider the X/Open form:

$set 1 OmUA
$ #To
1 To:
$ #From
2 From:
$ #Subject
3 Subject:

(where '$ ' is a comment).  I've written a parser that
treats comments beginning with '#' as special and allows
'#' instead of the number.  Thus

$set 1 OmUA
$ #To
# To:
$ #From
# From:
$ #Subject
# Subject:

generates

#ifndef __msgsH
#define __msgsH

#define SETOmUA    1
#define OmUATo    1
#define OmUAFrom    2
#define OmUASubject    3

#endif

It would be nice to be able to rely on this kind of functionality.

--
Alphalpha Software, Inc.    |    [e-mail]
[e-mail]        |-----------------------------------
617/646-7703 (voice/fax)    |    Proline BBS: 617/641-3722

I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

Volume-Number: Volume 20, Number 90

shar.overview.d.8224
echo overview.e
cat >overview.e <<'shar.overview.e.8224'
From [e-mail]  Wed Jul  4 00:21:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03957; Wed, 4 Jul 90 00:21:06 -0400
Posted-Date: 3 Jul 90 21:07:30 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21932; Tue, 3 Jul 90 23:21:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24926; Tue, 3 Jul 90 23:08:43 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 3 Jul 90 21:07:30 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

>From:  [e-mail] (Guy Harris)
>In other words, I don't think there's a solution to the problem of "oh
>dear, how are we going to get all our applications modified to put out
>grammatically-correct messages in different languages without having to
>examine all the code that generates messages and possibly rewrite some
>of that code" other than teaching the system a fair bit about lots of
>human languages.

Might as well leave out the clause "other than ...".

Perhaps we could persuade those who think there should be a simple rule
for writing just one message text when programming for a variety of
cultures to use Esperanto for their messages.  At least that way they
will be understood just as readily by all customers..  :-)

Volume-Number: Volume 20, Number 92

shar.overview.e.8224
echo overview.f
cat >overview.f <<'shar.overview.f.8224'
From [e-mail]  Wed Jul  4 00:21:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04324; Wed, 4 Jul 90 00:21:54 -0400
Posted-Date: 3 Jul 90 22:43:54 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21949; Tue, 3 Jul 90 23:21:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24994; Tue, 3 Jul 90 23:11:45 cdt
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jul 90 22:43:54 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Henry Spencer)

>From:  Jason Zions <[e-mail]>
>How about because it constrains implementations to make DNI
>kernel-resident?

Nonsense.  Nothing in 1003.n constrains implementations to make anything
kernel-resident.  Things like read() are functions, which may or may not
reflect the primitives of the underlying kernel.  They are merely required
to communicate -- somehow -- with something that performs the required
services.

Why have two different kinds of endpoints for I/O?  We already have one
which is general enough to encompass almost every kind of I/O under the sun.

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented. What does it mean to seek() on a network endpoint?

Read()/write() are stream operations that work perfectly well as record
operations too.  As witness Unix ttys, which are record-oriented devices
on input, and Unix magtapes, which are record-oriented both ways.  As for
what it means to seek on a network endpoint, exactly the same as it means
to seek on a tty:  probably nothing.  But why invent new mechanisms for
I/O when the old ones will do perfectly well?

"Don't fix it if it ain't broken."

                                         Henry Spencer at U of Toronto Zoology
                                          [e-mail]   utzoo!henry

Volume-Number: Volume 20, Number 93

shar.overview.f.8224
echo overview.g
cat >overview.g <<'shar.overview.g.8224'
From [e-mail]  Wed Jul  4 00:22:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04393; Wed, 4 Jul 90 00:22:02 -0400
Posted-Date: 3 Jul 90 18:19:11 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA21955; Tue, 3 Jul 90 23:21:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA25056; Tue, 3 Jul 90 23:15:20 cdt
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 3 Jul 90 18:19:11 GMT
Apparently-To: [e-mail]

From:  [e-mail] (peter da silva)

In article <[e-mail]> From: [e-mail] (Jason Zions)
> Read()/write() are stream operations; only TCP is a stream transport
> provider. OSI TP0/2/4 maps much more closely to stdio and fgets()/fputs()
> in that it is record-oriented.

The same is true of a UNIX tty device with canonical processing. So?

> What does it mean to seek() on a network endpoint?

What does it mean to seek() on a pipe?
--
Peter da Silva.   `-_-'
[phone].
<[e-mail]>

Volume-Number: Volume 20, Number 94

shar.overview.g.8224
echo overview.h
cat >overview.h <<'shar.overview.h.8224'
From [e-mail]  Wed Jul  4 12:27:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10176; Wed, 4 Jul 90 12:27:27 -0400
Posted-Date: 4 Jul 90 08:55:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA13158; Wed, 4 Jul 90 11:27:23 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00290; Mon, 4 Jun 90 11:19:24 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tsa.co.uk![e-mail]
Organization: The Standard Answer Ltd.
Date: 4 Jul 90 08:55:34 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

In article <[e-mail]> [e-mail] (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 <[e-mail]>,
> 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

shar.overview.h.8224
echo overview.i
cat >overview.i <<'shar.overview.i.8224'
From [e-mail]  Wed Jul  4 13:57:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18668; Wed, 4 Jul 90 13:57:59 -0400
Posted-Date: 3 Jul 90 18:12:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA16493; Wed, 4 Jul 90 12:57:54 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00816; Wed, 4 Jul 90 12:43:42 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 3 Jul 90 18:12:00 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented.

Standard I/O, and "fgets()"/"fputs()" in particular, are
record-oriented?  News to me; I thought standard I/O offered byte
streams, and "fgets()" read stuff from that stream until it hit a
newline or EOF, and "fputs" put bytes from a string out onto that
stream.

For that matter, raw magtapes are also record oriented, and "read()" and
"write()" work fine on them.  I don't see the problem with TPn; a single
"write()" could either be turned into one packet, or broken up
arbitrarily into N packets if there's a maximum packet size.  If you
*want* to have a correspondence between "send it" calls and records, I
see no problem with providing additional calls to do that, but I also
don't see any problem with hiding record boundaries, if necessary, from
applications that *want* to just send byte streams over TPn.

>What does it mean to seek() on a network endpoint?

What does it mean to "seek()" on a tty?

Volume-Number: Volume 20, Number 96

shar.overview.i.8224
echo overview.j
cat >overview.j <<'shar.overview.j.8224'
From [e-mail]  Thu Jul  5 17:50:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29638; Thu, 5 Jul 90 17:50:49 -0400
Posted-Date: 5 Jul 90 03:40:11 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07699; Thu, 5 Jul 90 16:50:46 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04772; Thu, 5 Jul 90 16:01:15 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 5 Jul 90 03:40:11 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> uunet!tsa.co.uk![e-mail] 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

shar.overview.j.8224
echo overview.k
cat >overview.k <<'shar.overview.k.8224'
From [e-mail]  Thu Jul  5 17:50:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29670; Thu, 5 Jul 90 17:50:56 -0400
Posted-Date: 5 Jul 90 13:26:58 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA07707; Thu, 5 Jul 90 16:50:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04827; Thu, 5 Jul 90 16:03:13 cdt
From: Karl Heuer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 5 Jul 90 13:26:58 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Karl Heuer)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>As for what it means to seek on a network endpoint, exactly the same as it
>means to seek on a tty: probably nothing.

Better yet, it should return an error (like an attempt to seek on a pipe).  I
don't think there's any excuse for tty seek having been defined as a no-op in
the first place; it's too bad POSIX didn't require this to be fixed.  (Is
there any reliable way to tell whether a given fd is seekable?)

Volume-Number: Volume 20, Number 98

shar.overview.k.8224
echo overview.l
cat >overview.l <<'shar.overview.l.8224'
From [e-mail]  Thu Jul  5 20:32:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13819; Thu, 5 Jul 90 20:32:28 -0400
Posted-Date: 5 Jul 90 21:24:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19756; Thu, 5 Jul 90 19:32:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05492; Thu, 5 Jul 90 19:18:46 cdt
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: correction (compression algorithm patents)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Jul 90 21:24:17 GMT
Apparently-To: [e-mail]

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

Five people have now brought to my attention that my
recent editorial says the compress/uncompress algorithm is
copyrighted: Dave Grindelman, Guy Harris, Keith Bostic, Randall
Howard, and Hugh Redelmeier.  That's wrong.  It isn't
copyrighted, it's patented.  My apologies to anyone I mislead.

Randall's note contains a lot of interesting details that it's worth posting
and he's given me permission to post it.
I've appended it.

Jeff

=====
[From Randall Howard]

    Actually the problem is not that the compress algorithm is copyrighted
but that it is PATENTED by Welch (the "W" in the LZW name of the algorithm).
The patent is currently held by Unisys Corporation and they make money
from licence fees on that patent because of the use of LZW encoding
in the new high-speed modems.  Note that the Lempel-Ziv algorithm
is apparently not patented, but just the Welch variant as is found in the
UNIX compress utility.  Therefore, at the cost of inventing a new file
compression standard, it would be possible to escape licence fees by
using a different variant of LZ compression.

    [Editor: Keith Bostic says both are patented:
    original Ziv-Lempel is patent number 4,464,650,
    and the more powerful LZW method is #4,558,302.
    He goes on to say, however, that LZW lacks adaptive table reset
    and other features in compress, and so may not apply.]

    The implications of this are that no one may produce the same
output as compress produces, regardless of the program that produced
that output, without being subject to the patent.  I.e., it is independent
of the actually coding used, unlike copyright.  Therefore, all of the PD
versions of compress are currently in violation, as is BSD.

    Representatives of Unisys at the POSIX.2 meetings claimed that
the Unisys Legal Department is pursuing the licensing of compress.  In fact,
unlike copyright or trade secret protection, patent protection does not
diminish because the holder of the patent is not diligent in seeking damages
or preventing unauthorized use.  Witness the large royalty payout by
Japanese semiconductor companies to Texas Instruments because they held
the patent on the concept of something as fundamental as integrated circuits.
This licence payout spans a period of over 20 years.  In addition,
Unisys representatives claim that Phil Karn's PKZIP, which uses the
LZW compression algorithm, is a licenced user of the Unisys patent and
that a fee (rumoured to be somewhere in the $10,000 to $20,000 US range)
has been paid up front in lieu of individual royalties.

    The ramifications for POSIX.2a are unclear.  Currently, there are members
of the working group that say that they would object if a patented
algorithm were required by the standard if ANY FEE WHATSOEVER (even if $1)
were required to use it.  (There are, however, precedents for standards
working in areas of patents in such areas as networking, modems, and
hardware bus structures.  It appears that we software people have not
"grown up" as much when it comes to issues of licensing.  Who has ever
hear of "public domain hardware"?)  Some people suggested that Unisys
should allow relatively free use of the patent but should profit from
publicity rights from a citation in every POSIX.2a product manual that
contains compress.  Therefore, there are currently negotiations underway
to see what kind of "special deal" Unisys would be willing to cut for the
use strictly in implementations of POSIX.2a.  Depending on the outcome
of these negotiations, compress would either be dropped, re-engineered,
or retained.

Volume-Number: Volume 20, Number 101

shar.overview.l.8224
echo overview.m
cat >overview.m <<'shar.overview.m.8224'
From [e-mail]  Sat Jul  7 10:59:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13763; Sat, 7 Jul 90 10:59:03 -0400
Posted-Date: 6 Jul 90 10:27:31 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00803; Sat, 7 Jul 90 09:58:59 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA11081; Sat, 7 Jul 90 09:54:23 cdt
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: correction (compression algorithm patents)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tsa.co.uk![e-mail]
Organization: The Standard Answer Ltd.
Date: 6 Jul 90 10:27:31 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

>From:  [e-mail] (Jeffrey S. Haemer) quoting Randall Howard
>
>    The ramifications [of the fact that the LZ and LZW compression
>algorithms are patented ] for POSIX.2a are unclear.  Currently, there
>are members of the working group that say that they would object if a
>patented >algorithm were required by the standard if ANY FEE WHATSOEVER
>(even if $1) were required to use it.  (There are, however, precedents
>for standards working in areas of patents in such areas as networking,
>modems, and hardware bus structures.  It appears that we software people
>have not "grown up" as much when it comes to issues of licensing.

For the record, from (normative) Annex A of IEC/ISO Directives -- Part 2:
Methodology, 1989:

   If, in exceptional cases, technical reasons justify the preparation
   of an International Standard in terms which include that use of a
   patented item, there is no objection in principle to such a step,
   even if the terms are such that there is no alternative means of
   compliance.  In such a case, the following procedures shall be
   complied with.

      a)  ISO and IEC cannot give authoritative or comprehensive information
      about evidence, validity and scope of patent and like rights but it
      is desirable that the fullest information be disclosed.  Therefore
      the originator of a proposal of such a kind shall draw the technical
      committee's or subcommittee's attention to any known patent and like
      rights on a worldwide basis or any known pending applications,
      although ISO and IEC are not in a position to guarantee the authority
      of any such information.

      b)  If the proposal is accepted on technical grounds, the originator
      shall ask any known patent holder for a statement that he would be
      willing to negotiate licences under patent and like rights for
      applicants throughout the world on reasonable terms and conditions.
      A record of the patent holder's statement shall be placed in the
      files of the ISO Central Secretariat or the IEC Central Office, as
      appropriate, and shall be referred to in the relevant international
      standard.  If the patent holder does not provide such a statement,
      the technical committee shall not proceed with the inclusion of the
      patented item unless the respective Council gives permission.

      c)  Should it be revealed after publication of the International
      Standard that licences under a patent and like rights cannot be
      obtained under reasonable terms and conditions, the International
      Standard shall be referred back to the technical committee for
      further consideration.

(The Councils of IEC and ISO are defined as ``the ultimate authority for
the technical work...'')

And from section 7, IEEE Standards Manual, April 1988:

   7. Patents

   There is no objection in principle to drafting a proposed IEEE standard
   in terms that include the use of a patented item, if it is considered
   that technical reasons justify this approach.

   7.1 Disclaimer

   The following note shall appear in all IEEE standards:

      ``IEEE standards documents are adopted by the Institute of Electrical
      and Electronic Engineers without regard to whether their adoption may
      involve patents on articles, materials, or processes.  Such adoption
      does not assume any liability to any patent owner, nor does it assume
      any obligation to any parties whatever adopting the standards
      documents.''

(This note duly appears in IEEE Std. 1003.1:1988, facing the title page.)

Think I prefer ISO's cautious but realistic approach to the IEEE's mere
shrugging off of any blame for any consequences whatever of any action it
cares to take.
--
Dominic Dunlop

Volume-Number: Volume 20, Number 109

shar.overview.m.8224
echo overview.n
cat >overview.n <<'shar.overview.n.8224'
From [e-mail]  Sat Jul 14 04:39:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03158; Sat, 14 Jul 90 04:39:39 -0400
Posted-Date: 12 Jul 90 23:23:25 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14484; Sat, 14 Jul 90 01:06:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA21293; Fri, 13 Jul 90 23:55:25 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: FZI Forschungszentrum Informatik, Karlsruhe, West-Germany
Date: 12 Jul 90 23:23:25 GMT
Apparently-To: [e-mail]

From:  [e-mail]

--- archives and tapes ---

First, I have to admit that I haven't read the latest standard's version,
but I do have strong feelings about data archives and transport.

Both tar and cpio are highly deficient for properly moving information
out and in. The first blunder of all is the limited format that does not
take care of long file names. There is a NAMSIZ parameter, so for heaven's
sake reserve sufficient space in the file descriptor of such a transport
archive! That's so fundamental that I will only talk about one other equally
nasty point about these formats, missing archive and volume labelling.

Next, you have to realize that both tar and cpio already do arrange data
in suitable chunks for transfer ('tar' reads 'tape archive'!). There is
no reason in the world why an ANSI tape file shall not be the envelope
for a UNIX-type archive. On the contrary, this will finally, after all
these years offer data labelling, both on the archive and on the tape
volumes. It is unbelievable that today, 1990, i have to look at a piece of
paper with my tar tape, which tells me about a number of archives on the
same medium and their position. Additionally, the ANSI tar standard
provides multi-volume data sets, so yet another stumbling stone can be
forgotten, if we only wrap tar' and cpio' archives in ANSI tape structures
(where tar' and cpio' are improved versions of tar and cpio).

Then, a point often forgotten: There is a real need to select, duplicate,
store data from some external medium (tape) on a different type of machine
than the one the tape is written on / to be read.  The proposal above will
make that an easy and safe operation, what cannot be claimed today. (Today,
ypou just have to have a guru around who knows alls kinds of different
machines and how they mix).

Finally: Yes, we do move archives across networks, but for most substantial
transfers of data in and out of our machines there is no adequate replacement
for sequential magnetic media. Posix has to take that into account, or we
will be burdened with those problems of today.

Karl Kleine
FZI Forschungszentrum Informatik, Karlsruhe, West-Germany;  [e-mail]



Volume-Number: Volume 20, Number 125

shar.overview.n.8224
echo overview.o
cat >overview.o <<'shar.overview.o.8224'
From [e-mail]  Sun Jul 15 19:33:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08081; Sun, 15 Jul 90 19:33:52 -0400
Posted-Date: 14 Jul 90 23:27:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA00999; Sun, 15 Jul 90 18:33:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22977; Sun, 15 Jul 90 16:55:13 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface / TAPES
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 14 Jul 90 23:27:34 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)


>Then, a point often forgotten: There is a real need to select, duplicate,
>store data from some external medium (tape) on a different type of machine
>than the one the tape is written on / to be read.  The proposal above will
>make that an easy and safe operation,

Really?  The proposal above will deal with moving stuff from a machine
with a QIC-150-type 1/4" tape drive that can't write QIC-24 tapes to a
machine with a QIC-24-type 1/4" tape drive that can't read QIC-150 or
QIC-120 tapes?  Neat trick!

>what cannot be claimed today. (Today, ypou just have to have a guru
>around who knows alls kinds of different machines and how they mix).

"The proposal above" seems to be "put a 'tar' or 'cpio' archive as one
file within an ANSI-labelled tape."  I fail to see how that makes things
any better; if the problems are with variations between "cpio" and "tar"
formats on different machines, wrapping ANSI labels around the "tar" or
"cpio" data doesn't seem to make things any better.

If the *real* fix is in the "tar'" and "cpio'" formats you list, what do
the ANSI labels buy you other than multi-volume support?

>Finally: Yes, we do move archives across networks, but for most substantial
>transfers of data in and out of our machines there is no adequate replacement
>for sequential magnetic media.

By "data" do you mean "data as opposed to programs"?  If not, do any of
the folks who have retrieved, say, the X11 source via FTP or UUCP have
any comments on the above claim? I sucked the entire X11R3 distribution
to our site via UUCP; I would have done the same with the X11R4 format,
except that somebody already had it and offered to put it on 1/4" tapes
- fortunately, a 1/4" format we can read; they put it on a "tar" tape,
though, so ANSI tape labels contributed nothing....

I suspect the amount of software moved into our site via UUCP is at
least a significant fraction of the amount of software moved into our
site via magtapes.


Volume-Number: Volume 20, Number 128

shar.overview.o.8224
exit