pas@unhd.unh.edu (Paul A. Sand) (01/30/91)
In article <23975:Jan2516:36:5891@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Some versions of realloc() return the original pointer rather than 0 if >they run out of memory. So you have to code the malloc()/bcopy()/free() >sequence yourself if you want error checking. Other posters have pointed out that such realloc()'s are seriously broken, but I wonder how many versions "some versions" actually are. A brief check of my portability references (Jaeschke's _Portability and the C Language_, Rabinowitz's and Schaap's _Portable C_, 1st and 3rd editions of Harbison & Steele) doesn't turn up any warnings about such behavior. (And these folks seem to warn about *very* unlikely things.) But as long as I'm reading, I did notice a howler in Jaeschke's text, on page 320: You should ALWAYS use realloc as follows: ptr = realloc(ptr, new_size); Emphasis is Jaeschke's. Even a tyro like me can recognize that you are in big trouble if (a) the realloc() fails, (b) ptr is your only access to the block, and (c) you had something important there. -- -- Paul A. Sand | -- University of New Hampshire | I ain't here on business, baby. -- uunet!unhd!pas | I'm only here for fun. -- pas@unhd.unh.edu |