From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,df854b5838c3e14
X-Google-Attributes: gid109fba,public
X-Google-Thread: 10db24,fec75f150a0d78f5
X-Google-Attributes: gid10db24,public
X-Google-Thread: 1014db,df854b5838c3e14
X-Google-Attributes: gid1014db,public
X-Google-Thread: 103376,df854b5838c3e14
X-Google-Attributes: gid103376,public
From: emery@grebyn.com (David Emery)
Subject: Re: POSIX/Unix conformance (was: ANSI C and POSIX ...)
Date: 1996/04/08
Message-ID: <emery-0804961940190001@line297.nwm.mindlink.net>#1/1
X-Deja-AN: 146465260
references: <JSA.96Feb16135027@organon.com> <dewar.828912460@schonberg>
 <4kb1l1$ajm@solutions.solon.com> <dewar.828987795@schonberg>
 <4kcf2q$mll@solutions.solon.com>
organization: MIND LINK! - British Columbia, Canada
newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
Date: 1996-04-08T00:00:00+00:00
List-Id: <comp.lang.ada>

There are actually two separate issues that no one has adequately
addressed:

   1.  POSIX conformance
   2.  Unix(tm) conformance

Let me try to summarize POSIX conformance.  First, there are a series of
POSIX standards, IEEE 1003.1 and 1003.2 are the primary standards of interest
here.  These are also ISO standards ISO 9945-1 and 9945-2 (respectively).
And, they are U.S. FIPS standards (FIPS 151-2).  

POSIX conformance is defined by two documents, the relevant standard and
the set of test assertions.  The test assertions specify a series of
tests that a conforming implementation pass.  The assertions themselves are
NOT executable.  

Instead, a POSIX tester translates these assertions into a test suite.

U.S. NIST has developed a set of validation procedures based on commercial
testing.  A POSIX validation tester submits his test suite to NIST, and NIST
'validates' this suite against the test assertions.  The test suite itself
remains the property of the testing organization.  The goal of the NIST
'validation' is to certify the testing organization as acceptable to issue
NIST FIPS conformance certificates for the implementation.  NIST maintains a
list of conforming POSIX/FIPS 151-2 implementations.  

This differs from Ada testing in a critical way:  For Ada validation, the
test suite iteself is freely available.  It is (relatively) easy to verify
that an Ada validation (ACVC) test matches the standard, and there is a 
single test suite for all validations.  For POSIX testing, each tester has
his own test suite, and we have to trust NIST and the testing vendor that
the vendor's test actually tests POSIX compliance.  


As regards to conformance with the Unix(tm) trademark, this is based on
a set of procedures established by (the late) X/Open.  I'm not familiar
with X/Open's requirements to use the "Unix" trademark.

Note that it's quite possible to validate non-Unix operating systems as
POSIX-compliant.  In fact one of the earliest validations was for 
Unisys CTOS, which is NOT a flavor of Unix.  I believe that there is a version
of Windows NT which is POSIX-compliant, and I recall hearing something about
a POSIX version of Windows 95.  And then there's "Open VMS" (an oxymoron, IMHO),
which is a POSIX-compliant version of VMS.  In these cases, what we have is
a POSIX interface on top of a Non-Unix operating system.

            dave