Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucsd!ucbvax!usenix!std-unix
From: karish@mindcrf.uucp (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Question about atexit()
Message-ID: <466@usenix.ORG>
Date: 27 Aug 90 18:32:27 GMT
References: <444@usenix.ORG> <443@usenix.ORG> <442@usenix.ORG> <450@usenix.ORG>
Sender: std-unix@usenix.ORG
Organization: Mindcraft, Inc.
Lines: 54
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

From:  karish@mindcrf.uucp (Chuck Karish)

In article <450@usenix.ORG> Donn Terry wrote about the issue of exactly
what support of the C standard need be provided by a 1003.1-conforming
system.  I've discussed the issue with him by phone and am satisfied
that we understand the underlying issues the same way, but I'm still
concerned by the wording of the referenced article.

>The list at the beginning of chapter 8 is ...
>a list of functions *from the C standard* that must be provided
>by a "common usage" implementation.

It is also a list of functions that must be provided by a system
providing C Standard Language-Dependent System Support:  "Implementors
shall meet the requirements of Section 8 using for reference the C
Standard" (P1003.1a/D5, 1.2.3.2, ll. 168-169).

>That list will (as far as I can
>predict) be completely removed from the first version of the standard
>that doesn't discuss common usage, and rely solely on the pointer from
>POSIX.1 C-language binding to X3.159/ISO 9xxx ...
>for all Standard C functions.

This implies that future versions of POSIX.1 will require that a full
implementation of Standard C be present.  There is no such requirement
in the current document, even for the C standard option.  I'd like to
see the list stay, if only to make it easier to assess the impact of
future changes to Standard C on POSIX compliance: whether upgrading the
C compiler and libraries will break existing code.

>Doug Gwyn is right: specify the Standard C conformant option to POSIX
>(or simply specify Standard C) and you'll get atexit(). 

I disagree.  Certainly if the customer specifies that a full
implementation of standard C be part of the package, it will be
present, but POSIX.1 doesn't require this.  This is an issue that
should be resolved when the profile is drawn up to describe a complete
system.  It would seem to be outside the scope of the 1003.1 effort.

>Also, until POSIX.1 is stated in terms soley of Standard C (when it
>ceases to be necessary), there is nothing at all to prevent POSIX.4 from
>requiring that atexit() with the Standard C semantics be provided in
>common-usage implementations.

This is an excellent suggestion, which POSIX.4 should adopt
regardless of the status of C standard support in the POSIX.1
standard.  Every standard should specify its critical reliances
on the provisions of other standards.
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000		

Volume-Number: Volume 21, Number 64