home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11691 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  1.4 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!allegra!alice!ark
  2. From: ark@alice.att.com (Andrew Koenig)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Pointers outside of array boundary
  5. Message-ID: <23344@alice.att.com>
  6. Date: 29 Jul 92 04:22:30 GMT
  7. Article-I.D.: alice.23344
  8. References: <1992Jul28.180945.22332@hubcap.clemson.edu>
  9. Reply-To: ark@alice.UUCP ()
  10. Organization: AT&T Bell Laboratories, Liberty Corner NJ
  11. Lines: 21
  12.  
  13. In article <1992Jul28.180945.22332@hubcap.clemson.edu> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
  14.  
  15. >     float x = malloc(10*sizeof(float));
  16. >     --x;
  17.  
  18. > My question is: Can anyone name an existing machine on which this code
  19. > could fail, or give a really convincing hypothetical argument why it
  20. > is a bad idea?
  21.  
  22. The most fundamental reason is that it WILL fail in any implementation
  23. that rigorously checks for conformance with the Standard.
  24.  
  25. A more practical reason: suppose you're on a machine where addresses are
  26. (segment,offset) pairs, such as on Intel hardware.  Suppose further that
  27. the hardware checks for offset underflow or overflow in address arithmetic.
  28. Then it is entirely possible for malloc to return a pointer to the beginning
  29. of a segment and --x to cause it to underflow.  Worse, the error might
  30. be detected only when you have the bad luck to call malloc at the wrong time.
  31. -- 
  32.                 --Andrew Koenig
  33.                   ark@europa.att.com
  34.