home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0052.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  2.7 KB
  1. From: jeffrey@algor2.algorists.com (Jeffrey Kegler)
  2.  
  3. In article <6649@portia.Stanford.EDU> karish@forel.stanford.edu (Chuck Karish) writes:
  4.  
  5. >According to Section 2.8.2.1 of the 1003.1 document, "If there are no
  6. >feature test macros present in a program, only the set of symbols
  7. >defined by the C standard shall be present".  This means that the
  8. >symbols may be present, but they must be concealed by a feature test
  9. >macro:
  10.  
  11. >#ifdef    _C_LIBRARY
  12. >#define _LOW(__v)               ( (__v) & 0377)
  13. >#define _HIGH(__v)              ( ((__v) >> 8) & 0377)
  14. >#endif
  15.  
  16. This raises some questions.  Does the "set of symbols *defined* by
  17. the C standard" include those *reserved* by the C standard?  2.8.1
  18. states of the namespaces reserved by the dpANS that they are reserved
  19. by POSIX also.
  20.  
  21. The symbols can be reserved (I hope this is inclusive) for
  22.  
  23. 1) Current use by dpANS.
  24. 2) Use by alternate dpANS C implementations (including future ones).
  25. 3) Future use by POSIX.
  26. 4) Current use by POSIX as allowed by dpANS to specific implementations.
  27.  
  28. I read POSIX 1003.1 2.8.2.1 as saying that uses of the last type will
  29. not occur.  But feature test macros macros would have to be tested
  30. ("#ifdef _FEATURE") and file scope identifiers would have to be both
  31. defined and tested if they are used as the mechanism to allow
  32. idempotent headers (headers capable of harmless multiple inclusion, as
  33. required by dpANS and POSIX).
  34.  
  35. This point is academic from the point of view of the application,
  36. since dpANS prohibits its use of the reserved namespace, anyway
  37. (otherwise behavior is undefined - dpANS 4.1.2.1).  However it does
  38. seem relevant to the POSIX implementer.
  39.  
  40. Assume I am created headers for a POSIX implementation.  I am
  41. providing an ANSI C comforming compiler, and anticipate others will be
  42. added by third parties.  These are entitled to use the namespace of
  43. identifiers starting with underscore as they please.  But in my
  44. headers I am required to use precisely this namespace for my feature
  45. test macros.  What prevents them from conflicting with a dpANS
  46. compiler (say, a future version of GNU C) that someone ports to my
  47. POSIX implementation?
  48.  
  49. In quaranteeing header idempotence, I seem to have a choice of 1)
  50. using reserved identifiers and risking conflicts with the dpANS
  51. implementation and 2) using non-reserved identifiers and risking
  52. conflicts with the application's namespace.  Am I missing something?
  53. Might each dpANS implementation ported to a POSIX implementation
  54. require its own set of POSIX headers due to namespace conflicts?
  55. -- 
  56.  
  57. Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
  58. jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey
  59. 1762 Wainwright DR, Reston VA 22090
  60.  
  61. Volume-Number: Volume 17, Number 61
  62.  
  63.  
  64.