home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!not-for-mail
- From: jason@cnd.hp.com (Jason Zions)
- Newsgroups: comp.std.unix
- Subject: Re: Posix compliance (application)
- Date: 28 Jan 1993 11:19:53 -0800
- Organization: Hewlett Packard, Network & System Management Division
- Lines: 30
- Sender: sef@ftp.UU.NET
- Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
- Message-ID: <1k9bkpINN6qe@ftp.UU.NET>
- NNTP-Posting-Host: ftp.uu.net
- X-Submissions: std-unix@uunet.uu.net
-
- Submitted-by: jason@cnd.hp.com (Jason Zions)
-
- >Where may I obtain information about certifying that my *application* is
- >POSIX compliant? I know about the NIST, X/Open and AT&T conformance suites,
- >but as I read about those, I surmise that they are geared to *operating system*
- >compliance as opposed to application compliance. Can someone assist me?
-
- Ah, yes, the "POSIX Conforming Application" question.
-
- This is a much tougher thing to test, although I seem to recall Mindcraft
- talking about having a product that did this; the talk was back in April
- 1990 (the POSIX Snowbird meeting, anyway).
-
- An application is said to strictly conform to 1003.1 if it uses only things
- defined by that standard and the ones it relies on (e.g. ISO C). So, a test
- suite would have to make sure that every time your application invokes
- open() that you are using it in a way for which the standard defines
- functionality. Recall that there are many times the standard is deliberately
- silent on the way a conforming implementation behaves when an application
- takes some action; if your application ever takes that action, it no longer
- strictly conforms. For some interfaces (perhaps not open()), this checking
- may be equivalent to the Stopping Problem; I suspect full verification of
- application conformance is NP-Complete.
-
- 1003.2 will be even worse.
-
- Jason
-
-
- Volume-Number: Volume 30, Number 44
-