home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0026.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.9 KB
  1. From:  Doug Gwyn <gwyn@smoke.brl.mil>
  2.  
  3. In article <714@longway.TIC.COM> From:  Andy Tanenbaum <ast@cs.vu.nl>
  4. >If one replaced the *_t types by their definitions everywhere, then a
  5. >decision to change pid_t from, say, int, to, say, long, would require
  6. >a real expert to dig through all the code to find those int's that really
  7. >are pid_t's.
  8.  
  9. You miss an important point -- we're talking about system code provided
  10. by the IMPLEMENTOR, not application code.  Presumably the implementor
  11. IS a real expert, and furthermore is in charge of the decision about
  12. what specific typedefs will be used.  I suspect that many implementors
  13. will provide (for implementation use only) additional headers, say
  14. <sys/_types.h>, that define identifiers such as __pid_t that are just
  15. like the POSIX ones but taken from the name space reserved for use by
  16. implementations.  Then, for example, <sys/types.h> could contain:
  17.     /* <sys/types.h>: */
  18.     #include <sys/_types.h>
  19.     #define pid_t __pid_t
  20. and <signal.h> could contain:
  21.     /* <signal.h>: */
  22.     #include <sys/_types.h>
  23.     #ifdef _POSIX_SOURCE
  24.     extern int kill(__pid_t, int);
  25.     #endif
  26. which addresses the maintenance issue that the implementor might be
  27. faced with.  (Applications are oblivious to all this substructure,
  28. which is the way things SHOULD be.)
  29.  
  30. >This then raises the question of how to make pid_t known.  In the example
  31. >implementation given, <sys/types.h> is included in raise.c.  If this is
  32. >indeed legal, then that is clearly one way to do it, as presumably all the
  33. >names introduced by <sys/types.h> are not present in the object file,
  34. >raise.o, and thus do not pollute the name space.
  35.  
  36. Yes, that was one of the points of the example.
  37.  
  38. >However, why do you urge not to put #include <sys/types.h> into <signal.h>
  39. >under protection of #ifdef _POSIX_SOURCE?
  40.  
  41. Because I don't think that use of _POSIX_SOURCE should pollute the
  42. name space beyond the minimum required for POSIX.
  43.  
  44. Volume-Number: Volume 20, Number 26
  45.  
  46.