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