home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16106 < prev    next >
Encoding:
Text File  |  1992-11-08  |  3.7 KB  |  94 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news
  3. From: scs@adam.mit.edu (Steve Summit)
  4. Subject: Re: Finding RAND_MAX and SEEK_POS (ANSI C)
  5. Message-ID: <1992Nov6.233844.12882@athena.mit.edu>
  6. Sender: news@athena.mit.edu (News system)
  7. Nntp-Posting-Host: adam.mit.edu
  8. Organization: none, at the moment
  9. References: <6507@news.duke.edu> <1992Oct30.170950.21366@klaava.Helsinki.FI>
  10. Date: Fri, 6 Nov 1992 23:38:44 GMT
  11. Lines: 81
  12.  
  13. In article <6507@news.duke.edu>, Ted A. Campbell (tcamp@acpub.duke.edu) writes:
  14. > At least two users--in very different parts of the world--have reported
  15. > that their Unix-based ANSI C compilers (one of them was using a version
  16. > of gcc) failed to find the constants SEEK_POS (for fsek()) and
  17. > RAND_MAX (for rand()).  
  18. > 
  19. > My documentation suggests that these constants ought to be defined
  20. > in ANSI-compliant systems...
  21.  
  22. Indeed they ought.  (In gcc's case, note that its ANSI compliance
  23. is most complete with respect to its parser; gcc often depends on
  24. local #include files and libraries.  If you're using gcc because
  25. it's ANSI-compliant and your vendor-supplied compiler isn't, the
  26. vendor-supplied header files aren't likely to be ANSI-compliant,
  27. either.)
  28.  
  29. > One user reported that he found SEEK_POS defined in <unistd.h>,
  30. > but I'm not aware of the meaning of this header file. 
  31.  
  32. It's a standard Posix header; I hadn't realized that both X3.159
  33. and 1003.1 defined the SEEK_* values.  (Posix uses them for lseek().)
  34.  
  35. > Perhaps someone can reveal these mysteries to me.  Should I include
  36. > default values for these constants (I wouldn't know what they should
  37. > be), or should I simply report that their compilers are broken?
  38.  
  39. Defaulting them can be tricky.  Read on...
  40.  
  41. In article <1992Oct30.170950.21366@klaava.Helsinki.FI>, Lars Wirzenius
  42. (wirzeniu@klaava.Helsinki.FI) writes:
  43. > You could provide a "port.h" or "config.h" header, and let the installer
  44. > of the program add defines for these macros to that header.  As a guess,
  45. > SEEK_SET would probably be 0 (especially on Unix systems where fseek is
  46. > built on lseek, which uses 0 for this purpose).
  47.  
  48. I frequently do things like
  49.  
  50.     #ifndef SEEK_SET
  51.     #define SEEK_SET 0
  52.     #endif
  53.  
  54. , because there are plenty of systems out there without these
  55. macros defined.  (Many systems still tell you, on their man
  56. pages, to use 0, 1, or 2 as the third argument to lseek or fseek.)
  57.  
  58. I was surprised just now to notice that the ANSI C Standard does
  59. *not* specify the numeric values for these macros (unless there's
  60. something I missed), so old code that does
  61.  
  62.     fseek(fp, 0L, 0);
  63.  
  64. could theoretically break on a system which (perversely, but
  65. apparently legally) chose to define SEEK_SET as 37.
  66.  
  67. > If you are not very
  68. > conserned about having an accurate value for RAND_MAX, the value 32767
  69. > should suffice.
  70.  
  71. I would *not* recommend providing a default value for RAND_MAX.
  72. Any code that is using RAND_MAX at all cares about the value more
  73. than just approximately.  On 16-bit machines, RAND_MAX is usually
  74. 32767; on 32-bit machines, it's often 2147483647.  The recommended
  75. way of generating random numbers in a specific range, namely
  76.  
  77.     rand() / (RAND_MAX / N)
  78.  
  79. is going to break badly if the value of RAND_MAX is wildly
  80. incorrect.  (It's extremely tempting to duck the RAND_MAX problem
  81. entirely by computing rand() % N, but doing so cannot be
  82. recommended; see a nearby article of mine, or the FAQ list, for
  83. more details.)
  84.  
  85. If the code finds itself on a system without RAND_MAX locally
  86. #defined, the person doing the installing will have to be asked
  87. to determine the appropriate value somehow.  (Alternately, as
  88. Lars suggested, you could supply your own random number generator,
  89. but doing so sort of defeats the purpose of having one in the
  90. standard library.)
  91.  
  92.                     Steve Summit
  93.                     scs@adam.mit.edu
  94.