home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 064 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Mon Aug 27 23:01:13 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA14478; Mon, 27 Aug 90 23:01:13 -0400
  4. Posted-Date: 27 Aug 90 18:32:27 GMT
  5. Received: by cs.utexas.edu (5.64/1.74) 
  6. From: mindcrf!karish@cs.utexas.edu (Chuck Karish)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Question about atexit()
  9. Message-Id: <466@usenix.ORG>
  10. References: <444@usenix.ORG> <443@usenix.ORG> <442@usenix.ORG> <450@usenix.ORG>
  11. Sender: std-unix@usenix.ORG
  12. Organization: Mindcraft, Inc.
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 27 Aug 90 18:32:27 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. From:  karish@mindcrf.uucp (Chuck Karish)
  19.  
  20. In article <450@usenix.ORG> Donn Terry wrote about the issue of exactly
  21. what support of the C standard need be provided by a 1003.1-conforming
  22. system.  I've discussed the issue with him by phone and am satisfied
  23. that we understand the underlying issues the same way, but I'm still
  24. concerned by the wording of the referenced article.
  25.  
  26. >The list at the beginning of chapter 8 is ...
  27. >a list of functions *from the C standard* that must be provided
  28. >by a "common usage" implementation.
  29.  
  30. It is also a list of functions that must be provided by a system
  31. providing C Standard Language-Dependent System Support:  "Implementors
  32. shall meet the requirements of Section 8 using for reference the C
  33. Standard" (P1003.1a/D5, 1.2.3.2, ll. 168-169).
  34.  
  35. >That list will (as far as I can
  36. >predict) be completely removed from the first version of the standard
  37. >that doesn't discuss common usage, and rely solely on the pointer from
  38. >POSIX.1 C-language binding to X3.159/ISO 9xxx ...
  39. >for all Standard C functions.
  40.  
  41. This implies that future versions of POSIX.1 will require that a full
  42. implementation of Standard C be present.  There is no such requirement
  43. in the current document, even for the C standard option.  I'd like to
  44. see the list stay, if only to make it easier to assess the impact of
  45. future changes to Standard C on POSIX compliance: whether upgrading the
  46. C compiler and libraries will break existing code.
  47.  
  48. >Doug Gwyn is right: specify the Standard C conformant option to POSIX
  49. >(or simply specify Standard C) and you'll get atexit(). 
  50.  
  51. I disagree.  Certainly if the customer specifies that a full
  52. implementation of standard C be part of the package, it will be
  53. present, but POSIX.1 doesn't require this.  This is an issue that
  54. should be resolved when the profile is drawn up to describe a complete
  55. system.  It would seem to be outside the scope of the 1003.1 effort.
  56.  
  57. >Also, until POSIX.1 is stated in terms soley of Standard C (when it
  58. >ceases to be necessary), there is nothing at all to prevent POSIX.4 from
  59. >requiring that atexit() with the Standard C semantics be provided in
  60. >common-usage implementations.
  61.  
  62. This is an excellent suggestion, which POSIX.4 should adopt
  63. regardless of the status of C standard support in the POSIX.1
  64. standard.  Every standard should specify its critical reliances
  65. on the provisions of other standards.
  66. -- 
  67.  
  68.     Chuck Karish        karish@mindcraft.com
  69.     Mindcraft, Inc.        (415) 323-9000        
  70.  
  71. Volume-Number: Volume 21, Number 64
  72.  
  73.