home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.13 / text0025.txt < prev    next >
Encoding:
Internet Message Format  |  1988-04-18  |  3.3 KB
  1. From: uunet!brl-smoke.ARPA!gwyn (Doug Gwyn )
  2.  
  3. In article <1086@bentley.UUCP> cox@bentley.UUCP (59463-MH Cox) writes:
  4. >The proposed ANSI standard C has produced
  5. >a lot of new data types:  size_t, time_t, etc.  I was starting to
  6. >adopt their "_t" convention for my own data types, when
  7. >I suddenly realized (excuse me, if this is obvious to everyone
  8. >else :-) I might be headed for a type clash with a future
  9. >ANSI C typedef.  Did the ANSI C committe intend to reserve all
  10. >typedefs of the form *_t for their own use?  Should I
  11. >avoid typedefs of this form in my applications?
  12.  
  13. The following is my own opinion and should not be taken
  14. as an official X3J11 response:
  15.  
  16. Only those portions of the name space explicitly identified
  17. in the ANSI C standard as reserved for implementation use
  18. are unsafe for portable applications to use.  *_t (where *
  19. starts with a alphabetic character) is not reserved except
  20. for the specific types such as time_t named in the standard.
  21.  
  22. However, you may have a problem if you define your own *_t
  23. types in a POSIX environment, since POSIX introduces some more
  24. types.  What IEEE Std 1003.1 should say, but as of Draft 12
  25. as modified so far during the balloting process does not say,
  26. is that inclusion of <sys/types.h> may define additional types
  27. (other than those explicitly named in the POSIX standard) with
  28. names of the form *_t.  What the revised draft currently says
  29. is that <sys/types.h> may define additional types having any
  30. names whatsoever; this is clearly not in line with the
  31. professed goal of "promoting portable applications".  A
  32. similar botch is found in IEEE Std 1003.1 <signal.h>, which
  33. should only allow (besides more SIG* names) additional macros
  34. having names of the form SA_*, but currently also allows any
  35. names whatsoever to be usurped by the implementation.
  36.  
  37. These problems with 1003.1 are in addition to the generic one
  38. of a contradiction between the requirements of ANSI C and of
  39. POSIX for what names the headers that they share can define.
  40. The X3J11 committee sent 1003.1 a letter explaining the
  41. problem and suggesting a simple solution (that in practice
  42. would usually be met by the application programmer arranging
  43. for <unistd.h> to be included before the headers in question).
  44. However, so far 1003.1 has come up with a different "solution"
  45. that merely avoids solving the problem.  My guess is that they
  46. don't understand the issue; or possibly they have yielded to
  47. pressure to bless the existing messy situation in the UNIX
  48. world as "already POSIX conformant", in which case one wonders
  49. what the point of the standard is.  (If you say that it is
  50. becoming mostly a marketing ploy rather than an aid to
  51. programmers, I might not disagree.)
  52.  
  53. Since it appears that 75% of the balloters have now voted yea
  54. on draft 1003.1, we are in danger of getting a standard that
  55. does not solve these fundamental portability problems.  I have
  56. been urging procurement specifications that require more than
  57. 1003.1 conformance, for example ANSI C and SVID compliance,
  58. with an order of precedence specified for cases where the
  59. several specifications conflict (with ANSI C first, since it
  60. is more basic and universal than the other specs).  This seems
  61. to be the only safe course given the weaknesses and
  62. incompleteness of 1003.1 as it now stands.  (It has gotten
  63. better than it was a year ago, though, mostly under NBS
  64. influence.)
  65.  
  66. Volume-Number: Volume 13, Number 27
  67.  
  68.