home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3009 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.5 KB
  1. Path: sparky!uunet!munnari.oz.au!goanna!ok
  2. From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
  3. Newsgroups: comp.std.c
  4. Subject: Re: fwrite+fread of pointer
  5. Message-ID: <15976@goanna.cs.rmit.oz.au>
  6. Date: 16 Nov 92 09:33:15 GMT
  7. References: <15935@goanna.cs.rmit.oz.au> <1992Nov13.101813.163@nntpd.lkg.dec.com> <1992Nov15.065204.22137@sq.sq.com>
  8. Organization: Comp Sci, RMIT, Melbourne, Australia
  9. Lines: 42
  10.  
  11. In article <1992Nov15.065204.22137@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
  12. > First, I take it that everyone agrees that the bytes read back from
  13. > the file have to be the same ones that were written out.  The question
  14. > then is whether the bytes that represent the pointer value &dummy have
  15. > to always be the same ones, during the life of the variable "dummy".
  16.  
  17. That is indeed the question.  For the benefit of some comp.std.c readers
  18. who have mistaken me for a novice who _wants_ to do this kind of thing,
  19. I'm not.  I have been arguing for a while in comp.lang.c that it would be
  20. a good thing if C compilers were to warn about fwrite(&x... or fread(&x...
  21. where x is of a type which can include pointers.  I have seen too many
  22. students get this wrong.  It is a particularly easy mistake to make:
  23.  
  24.     struct Tag { ... char field[20]; ... } x;
  25.     fwrite(&x, sizeof x, 1, f);
  26.  
  27. and then the instructor points out that `field' is supposed to hold
  28. file names and 20 is absurdly small, so the student changes it to
  29.  
  30.     struct Tag { ... char *field; ... } x;
  31.  
  32. and misses a couple of the fwrite()s.  I received mail from several people
  33. defending the fact that C compilers don't point out the problem, all of
  34. them taking the line that it _might_ be useful, though none of them cited
  35. an actual working program they had written or even read.  The question then
  36. arose:  is it EVER possible for a _portable_ program to write out a pointer
  37. and usefully read it back?
  38.  
  39. It was always clear that you should get the same _bytes_ back, but it was
  40. not clear to me that it has to be the same _pointer_.  Mark Brader has
  41. understood the question perfectly.
  42.  
  43. > My opinion is that they do; this opinion is based, somewhat shakily,
  44. > on the definition of an object as "a region of data space in the
  45. > execution environment", where the key word is "a".
  46.  
  47. The question can now be paraphrased:  is a pointer like a tensor, or like
  48. the components of a tensor?  I would regard a compacting garbage collector
  49. as simply changing the co\"ordinate system.  I have used hardware and
  50. software systems where stacks could be moved (in order to "stretch" them)
  51. while the owning thread was running.
  52.  
  53.