home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / std / c / 2538 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  1.2 KB
  1. Path: sparky!uunet!utcsri!utgpu!attcan!sobeco!philmtl!vedge!hendrik
  2. From: hendrik@vedge.UUCP (Hendrik Boom)
  3. Newsgroups: comp.std.c
  4. Subject: Re: <limits.h> and MB_LEN_MAX
  5. Message-ID: <28625@vedge.UUCP>
  6. Date: 28 Aug 92 16:14:24 GMT
  7. References: <1992Aug27.165044.4781@ready.eng.ready.com>
  8. Organization: Visual Edge Software, St. Laurent, Quebec
  9. Lines: 21
  10.  
  11. glenn@ready.com (Glenn Kasten) writes:
  12.  
  13. : <limits.h> is supposed to define MB_LEN_MAX.  Is it permissible for a
  14. : conforming implementation to define MB_LEN_MAX in terms of another
  15. : type, where that other type is not declared in <limits.h>?  In other
  16. : words, do header files have to be complete in themselves, or can they
  17. : require other header files to also be included, in order to be
  18. : usable?
  19.  
  20. It doesn't matter whether the include files even exist, as long as
  21. the compiler understands
  22.  
  23.     #include <limits.h>
  24.  
  25. to define the proper symbols, without any further effort being
  26. required of the programmer.  So you cannot require him to
  27. include anything else.  It is perfectly OK for the limits.h file
  28. (assuming the compiler doen't have it built in, and actually does
  29. read an actual file of C code), to contain its own #includes to include
  30. whatever it needs.
  31.  
  32.     hendrik
  33.