home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3343 < prev    next >
Encoding:
Text File  |  1993-01-08  |  1.4 KB  |  41 lines
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!bart!volpe
  2. From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Struct hack one last time (one last time)
  5. Message-ID: <1993Jan8.135644.18732@crd.ge.com>
  6. Date: 8 Jan 93 13:56:44 GMT
  7. References: <1993Jan7.221207.13818@leland.Stanford.EDU>
  8. Sender: volpe@bart (Christopher R Volpe)
  9. Reply-To: volpe@ausable.crd.ge.com
  10. Organization: GE Corporate Research & Development
  11. Lines: 27
  12. Nntp-Posting-Host: bart.crd.ge.com
  13.  
  14. In article <1993Jan7.221207.13818@leland.Stanford.EDU>, dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
  15. |> 
  16. |> This has nothing to do with malloc. The hypothetical compiler
  17. |> could simply insert this error checking information whenever
  18. |> it does a conversion from a (void *) to a (struct foo *). Again,
  19. |> the basic question is still unresolved here: can a conversion
  20. |> from one pointer type to another affect bytes other than those
  21. |> where the pointer variable is stored?
  22.  
  23. Of course not. What would happen in the following program?
  24.  
  25.     int main(void)
  26.     {
  27.       struct foo {double field[2];} *fp;
  28.       char bar[]="LongerThanSizeOfStructFoo";
  29.       fp = (struct foo *)bar;
  30.       /* Does the above cast modify the contents of bar? */
  31.       if (strcmp(bar,"LongerThanSizeOfStructFoo"))
  32.         fprintf(stderr,"Dumb-ass compiler\n");
  33.       return 0;
  34.     }
  35.  
  36. -- 
  37. ==================
  38. Chris Volpe
  39. G.E. Corporate R&D
  40. volpecr@crd.ge.com
  41.