🚀 go-pugleaf

From:  Doug Gwyn <gwyn@smoke.brl.mil>

In article <442@usenix.ORG> sp@mysteron.osf.org (Simon Patience) writes:
>It was pointed out to me that atexit() is not defined in 1003.1
>1988.

IEEE Std 1003.1-1988 didn't explicitly specify atexit() for the ANSI C-
compatible variant because several people on P1003 didn't like it.

If in your procurement specifications you specify conformance to both
ANSI X3.159-1989 and IEEE Std 1003.1, then the ANSI C conformance
requirement suffices to guarantee the provision of atexit() facilities.

Volume-Number: Volume 21, Number 45

From:  decot@hpisod2.cup.hp.com (Dave Decot)

> Recently, while discussing pthreads, I mentioned the use of atexit()
> as a way of helping thread cleanup if another thread calls exit().
> It was pointed out to me that atexit() is not defined in 1003.1
> 1988.

> I originally assumed that as .1 #includes all of ANSI C then atexit()
> would be able to be used in a conforming application but the book
> appears to indicate otherwise.

That assumption is false: only for one type of conformance is
all of ANSI C required.  For other types, only interfaces reflecting
"common usage in C" are required (a mostly undefined concept, unfortunately).

> So, can anyone in .1 explain whether atexit() really is required
> by .1 or not and if not, what the rationale is because I don't
> understand what the book is getting at.
> ...
> Simon Patience

atexit() is required when the implementation claims Standard C Language
support, since it is required by the C Standard.

atexit() is not required for implementations that claim Common Usage C
Language Support, although the fact must be documented that exit() does not
work as defined by the C standard.

For the reasons stated by Simon above, I personally think it should have
been included in the list of functions at the beginning of Chapter 8 of
POSIX.1-1988, but wasn't.

I would like to see it (or some kind of language independent version, at least,
with it required in the C binding) required by a future version of POSIX.1 .

In the mean time, I think it would be prudent for POSIX.4 and POSIX.4a to
require a C Standard conforming atexit() function.

Dave Decot

Volume-Number: Volume 21, Number 46

From:  Donn Terry <donn@hpfcrn.fc.hp.com>

The list at the beginning of chapter 8 is NOT a list of the requirements
of POSIX.1 on the C standard, although it is often misread that way.

It is a list of functions *from the C standard* that must be provided
by a "common usage" implementation.   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 (someone can fill in the
number, I forget) for all Standard C functions.

Also, if you read the requirements on common usage closely enough, you
realize that if you document it well enough, you probably could get
away with a Fortran compiler.  (OK... maybe that's an exaggeration, but
not by a whole lot.)

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

(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.  POSIX.4 could also simply require 
Standard C to be conformant, although I doubt that that would succeed
in balloting.)

Atexit() was omitted primarily because it was an X3J11 invetion that was
not rapidly being included in common usage compilers.  Since (transitional)
backwards compatabilty of implementations was a concern for POSIX.1,
that was a reasonable decision two years (or more) ago.

Donn Terry
Speaking only for myself, as I always have to say.

volume-Number: Volume 21, Number 52

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

From:  Doug Gwyn <gwyn@smoke.brl.mil>

In article <466@usenix.ORG> karish@mindcrf.uucp (Chuck Karish) writes:
>>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.

And indeed I did NOT say what Donn's paraphrase suggests.
I said that if you need atexit() you should specify conformance
to the C standard (as well as any POSIX conformance that you need).

Volume-Number: Volume 21, Number 66