home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2611 < prev    next >
Encoding:
Text File  |  1992-09-11  |  2.5 KB  |  69 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!usc!rpi!batcomputer!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: struct hack, and other out-of-array references
  5. Message-ID: <9225600.28053@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Sep07.104932.20060@x.co.uk> <1992Sep8.124655.1498@Urmel.Informatik.RWTH-Aachen.DE> <1992Sep10.014137.16209@sq.sq.com> <1992Sep10.213240.10272@thinkage.on.ca> <1992Sep11.012438.24377@jarvis.csri.toronto.edu>
  9. Date: Fri, 11 Sep 1992 14:07:47 GMT
  10. Lines: 57
  11.  
  12. flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
  13.  
  14. >dat@thinkage.on.ca (David Adrien Tanguay) writes:
  15. >>How is this any different from the array example?  p may point
  16. >>outside a[1], but it is still within the a object.  Similarly, ...
  17. >>is outside the f->s object but within the malloc object.
  18. >
  19. >The point is, "int a[5][5];" doesn't give you 25 ints, it gives you five arrays
  20. >of five ints each.  "(int(*)[5])malloc(5*sizeof(int[5]))" gives you
  21. >sizeof(int)*25 bytes which are ALSO five arrays of five ints.
  22. >
  23. >The first looks like this:
  24. >    int[5][5]:
  25. >        int[5]:
  26. >        int
  27. >        int
  28. >        int
  29. >        int
  30. >        int
  31. >        int[5]:
  32. >        ...
  33. >        ...
  34. >
  35. >And the second looks like this:
  36.  
  37.      malloc(25):
  38. >    char
  39. >    char
  40. >    char
  41. >    char
  42. >    ...
  43. >
  44. >Now that cast magically makes the second be close enough to the first in
  45. >outward appearance for all intents and purposes, but it's still the second
  46. >underneath.  Obviously in almost all compilers the memory layout will be the
  47. >same.  However, an environment such as Saber-C should be free to keep track of
  48. >the details and that's why I've always thought that this is a good
  49. >interpretation ruling.
  50. >
  51. >I'm not sure what you get when you take a pointer to that array five of array
  52. >five of int, cast it to a (char *), then cast it to a (int(*)[5]).
  53.  
  54. This sounds like a fairly reasonable explanation, but I still have some
  55. questions.
  56.  
  57. Do same considerations would apply if you tried to use a char[5][5] 
  58. array as a char[25] array? It sounds like you would say they
  59. do. What about casting a char[25] array to a char[5][5] array?
  60.  
  61. From what you're saying, the reason that casting the return
  62. value from malloc succeeds is only because malloc is "magic".
  63.  
  64. -- 
  65. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  66. This .signature virus is a self-referential statement that is true - but 
  67. you will only be able to consistently believe it if you copy it to your own
  68. .signature file!
  69.