home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0048.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  2.6 KB
  1. From: gwyn@brl.arpa (Doug Gwyn)
  2.  
  3. In article <6649@portia.Stanford.EDU> karish@forel.stanford.edu (Chuck Karish) writes:
  4. >According to Section 2.8.2.1 of the 1003.1 document, "If there are no
  5. >feature test macros present in a program, only the set of symbols
  6. >defined by the C standard shall be present".  This means that the
  7. >symbols may be present, but they must be concealed by a feature test
  8. >macro:
  9.  
  10. No, it doesn't -- because "the set of symbols defined by the C standard"
  11. can, and must, be construed as permitting all symbols that the C standard
  12. specifically reserves for the implementation, including _LOW etc.
  13.  
  14. >A header that conforms to POSIX 1003.1 as well as to the SVID and
  15. >X/OPEN standards will be a bit complicated.  A SVID-conforming program
  16. >that doesn't use POSIX extensions will expect UNIX identifiers to be
  17. >visible in the headers without use of a feature test macro.
  18.  
  19. That's true, but it's easily accomplished: the implementation merely
  20. needs to provide separate ways of invoking the compiler for POSIX/ANSI_C
  21. and "traditional" UNIX environments, in the latter case predefining some
  22. feature-test macro used to enable "traditional" extensions in the
  23. standard headers.  Of course the feature-test macro used for this must
  24. be in the name space reserved for implementations.
  25.  
  26. >Section 2.2.4 says "Any invocation of a library function that is
  27. >implemented as a macro shall expand to code that evaluates each of its
  28. >arguments only once ...".  However, WIFSIGNALED is defined in the
  29. >Standard as a macro, not as a library function.  It's legal to
  30. >evaluate these arguments twice; maybe not wise but, strictly
  31. >speaking, legal.
  32.  
  33. Again, that depends on how one interprets the wording.  Just because
  34. the spec requires that a particular "library function" be implemented
  35. as a macro does not keep it from being a library function implemented
  36. as a macro!  (And therefore subject to IEEE 1003.1 2.2.4.)  You can't
  37. argue that "library function" means genuine C function as opposed to
  38. function-like macro, either, because if that were a valid interpretation
  39. what would be the point of 2.2.4 talking about "library function that is
  40. implemented as a macro"?  I think the sanest interpretation is that even
  41. the things specifically stated in the spec to be (function-like) macros
  42. must be implemented to evaluate each of their arguments only once per
  43. macro invocation.  Thus, the WIFSIGNALED implementation you cited would
  44. be non-POSIX in that respect.
  45.  
  46. Perhaps the 1003.1 working group should clarify this along with the
  47. other post-publication changes they have planned.
  48.  
  49. Volume-Number: Volume 17, Number 57
  50.  
  51.  
  52.