sp@mysteron.osf.org (Simon Patience) (08/20/90)
From: sp@mysteron.osf.org (Simon Patience) 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 looked it up and sure enough it is not in the fabled list of ANSI C interfaces on page 141 and on page 183 it says that as exit() must do all the things _exit() does then this allows 1003.1 to ignore the atexit() function. I have to admit that I didn't understand that logic at all as it ignores the use of atexit() by the application to clean up inter-process state that the kernel cannot know about (such as data consistency in shared memory etc etc). 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. 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 Phone: (617) 621-8736 Open Software Foundation FAX: (617) 225-2782 11 Cambridge Center Email: sp@osf.org Cambridge MA 02142 uunet!osf.org!sp Volume-Number: Volume 21, Number 44
gwyn@smoke.brl.mil (Doug Gwyn) (08/21/90)
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
decot@hpisod2.cup.hp.com (Dave Decot) (08/21/90)
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
donn@hpfcrn.fc.hp.com (Donn Terry) (08/22/90)
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
karish@mindcrf.uucp (Chuck Karish) (08/28/90)
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
gwyn@smoke.brl.mil (Doug Gwyn) (08/28/90)
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