🚀 go-pugleaf

Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)

In article <1991Jun3.192534.28089@uunet.uu.net> clive@x.co.uk (Clive Feather) writes:

   Let us not. Let us RTFS instead.

Sigh.  RTFS, of course, stands for Read The Source.  Which, of course,
is the way these kinds of issues were once handled in Unix-land.
Later came "experiment", which also confirms the Posix method.  Since
nobody but the FSF seems to want real Posix.1 compliance and ANSI C
compliance in one system, I guess Reat The Standard will not be a good
clue to the behavior of Posix compliance claiming systems.

	-mib

[ Personal comment here:  the one vendor I personally know who had
  qualms about full POSIX compliance did so because of backwards-
  compatibility problems.  I suspect many vendors will have the
  same reservations.  So, how about it:  is full compliance worth
  breaking old programs/scripts?  --mod ]

Volume-Number: Volume 23, Number 85

Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)

In article <1991Jun3.225808.8518@uunet.uu.net> OFM writes:

   [ Personal comment here:  the one vendor I personally know who had
     qualms about full POSIX compliance did so because of backwards-
     compatibility problems.  I suspect many vendors will have the
     same reservations.  So, how about it:  is full compliance worth
     breaking old programs/scripts?  --mod ]

I'm most interested in Posix.1, so I'll address that.  If a compiler
switch is provided (like gcc -ansi) then full compliance is possible.
Given the _POSIX_SOURCE feature test macro, OS designers can load all
they want in, and turn it off only when _POSIX_SOURCE is defined.  I'm
writing a Posix compliant system which will also be 4.4BSD compatable;
I know whereof I speak.

	-mib


Volume-Number: Volume 23, Number 86

Submitted-by: sef@kithrup.COM (Sean Eric Fagan)

In article <1991Jun4.221021.26605@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>Given the _POSIX_SOURCE feature test macro, OS designers can load all
>they want in, and turn it off only when _POSIX_SOURCE is defined.  

That doesn't do everything.  Yes, it's possible to come up with a system
that is not only backwards compatible, but also provides full ANSI and/or
POSIX compliance (although it is not possible, necessarily, to mix old and
new).

Problems encountered:  namespace (have to get rid of everthing not defined
by ANSI for ANSI-only, everything not defined by POSIX for POSIX, and yet
have to worry about old binaries, as well as sources, that may rely on such
things [_iob was my favorite example, although there were several like items
in libc that we had to worry a lot about]); different semantics for things
of the same name (more an issue for section 1 and .2 compliance; things like
df and du have portable definitions under POSIX, which may or may not be
different from what old shell scripts expected).  One POSIX "optional"
feature, required by FIPS, was no-truncate; that is, if a filename exceeded
the maximum name length for the filesystem, return ENAMETOOLONG.  Do you
know how many programs out there are written to generate *unique* names in
14 characters or less, but still will try to create names with *more* than
14 characters?  B News, for example, I believe.

Again, yes, it's possible to get around all of these.  By having three
seperate libraries and header files (old, ansi, and posix).  By having two
sets of command trees (/old and /posix; e.g., /old/bin/df and
/posix/bin/df).  By defining bits in the executable's header to indicate
whether new features are to be used or not.  (Incidently, uSoft did that,
apparantly, with the OS/2 HPFS [high performance file system]:  older
programs which do not have the correct bit set in the header will not even
*see* the longer filenames.  I think this is wrong.  Just MHO, though 8-).)

>I'm
>writing a Posix compliant system which will also be 4.4BSD compatable;
>I know whereof I speak.

And I helped implement a POSIX-ANSI-and-X/Open-compliant-yet-backwards-
compatible system (OS, commands, and devsys) for a major vendor.  I also
know whereof I speak.  Many people reading this group can say the same
thing; most of them can probably come up with their own horror stories.  4.4
was intended to be largely POSIX compliant in the first place, and BSD
places less concern on backwards compatibility than commercial vendords do
(SCO, for example, can still execute, *and develop for*, XENIX/XT binaries;
can a BSD system say the same about BSD 4.1?).  Does this mean that SCO is
"better" than CSRG?  No, I didn't say that.  CSRG was able to come up with a
much better system, in many ways (including size, a personal peeve 8-)), and
most of their "customers" have sources anyway.  But the problems commercial
vendors have are very *real* problems.

At this point, I'm curious how SunOS did:  is it still able to run binaries
from 5, 10 years ago, without modification?  Can it still take object
modules from that long ago, and link them in with current libraries?  (Some
third-party people ship modules, and let the customer link them with
customized pieces, for example.)

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.


Volume-Number: Volume 23, Number 87

Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)

mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:

>   Let us not. Let us RTFS instead.

>Sigh.  RTFS, of course, stands for Read The Source.  

Actually, at least in this context, RTFS should be taken as "Read the
f-ing Standard", which in this case is unambiguous: the owner of a
"mode 040" file cannot read it.  What seems to be confusing people (at
least the ones who actually DID read the standard) is all of the stuff
about "alternative protection schemes".  That's all in there to permit
security enhancements like security labels (an "unclassified" process
can never read ANY "secret" files) and access control lists (I'll let
fred and george read the file, and harry write it when he is logged in
as group "operator").

>Since
>nobody but the FSF seems to want real Posix.1 compliance and ANSI C
>compliance in one system, I guess Reat The Standard will not be a good
>clue to the behavior of Posix compliance claiming systems.

I don't think that that's true.  I know of at least three vendors who
are at least striving to support ANSI C and POSIX.1 on the same
system.  It can be done.  The headers get pretty ugly, though.

David A. Willcox		"Just say 'NO' to universal drug testing"
Motorola MCG - Urbana		UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.		INET: willcox@urbana.mcd.mot.com
Urbana, IL 61801		FONE: 217-384-8534


Volume-Number: Volume 23, Number 93

Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)

In article <1991Jun5.201559.11784@uunet.uu.net> willcox@urbana.mcd.mot.com (David A Willcox) writes:

   >Since
   >nobody but the FSF seems to want real Posix.1 compliance and ANSI C
   >compliance in one system, I guess Reat The Standard will not be a good
   >clue to the behavior of Posix compliance claiming systems.

   I don't think that that's true.  I know of at least three vendors who
   are at least striving to support ANSI C and POSIX.1 on the same
   system.  It can be done.  The headers get pretty ugly, though.

What about name space cleanliness at link time?  All the systems seem
to punt on this one, and it really indicates their lack of commitment.

	-mib


Volume-Number: Volume 23, Number 99

Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)

In article <1991Jun3.225808.8518@uunet.uu.net>, mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
|> Since
|> nobody but the FSF seems to want real Posix.1 compliance and ANSI C
|> compliance in one system,  . . .

Just for the record: Revision 4.32 of the DG/UX operating system
has received certification from NIST for conformance with the 
POSIX.1 standard with ANSI C bindings.  The conformance testing was
done by Mindcraft.

We did use gcc from the FSF.

--------------------------------------------------------------------
Donald A. Lewine                (508) 870-9008 Voice
Data General Corporation        (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: lewine@cheshirecat.webo.dg.com


Volume-Number: Volume 24, Number 5