home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2588 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.2 KB  |  53 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!mcsun!Germany.EU.net!Urmel.Informatik.RWTH-Aachen.DE!physik.tu-muenchen.de!berg
  3. From: berg@physik.tu-muenchen.de (Stephen R. van den Berg)
  4. Subject: Re: struct hack, was Re: strcpy implementation question
  5. Message-ID: <1992Sep8.124655.1498@Urmel.Informatik.RWTH-Aachen.DE>
  6. Originator: berg@tabaqui
  7. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  8. Nntp-Posting-Host: tabaqui
  9. Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
  10. References: <9209040741.AA16120@enet-gw.pa.dec.com> <1992Sep07.104932.20060@x.co.uk>
  11. Date: Tue, 8 Sep 92 12:46:55 GMT
  12. Lines: 39
  13.  
  14. Clive Feather writes:
  15. >diamond@jit081.enet.dec.com writes:
  16. >>David Adrien Tanguay writes:
  17. >>>diamond@jit081.enet.dec.com writes:
  18. >>>>Israel Pinkas writes:
  19. >>>>> The variable length struct is a hack.  There is nothing in the language that
  20. >>>>> prevents the compiler from performing bounds checking on accesses to name.
  21. >>>> Bounds checking is not allowed to affect output of a valid but ugly program.
  22. >>> I had the impression that the last time it came up here the conclusion was
  23. >>> that this trick was not sanctioned[...]  3.3.6 "Additive Operators"
  24. >>> says that you aren't guaranteed to go past the end of an array object,
  25. >> No (though it was the conclusion of some others) and yes, respectively.
  26. >> You can't go past the end of an array object.  But if malloc() or some other
  27. >> variable has defined the end of the actual array object, then the + operator
  28. >> can get you that far, regardless of the declared type that some other array
  29. >> variable had before getting flattened to a pointer.
  30.  
  31. >But there is an intepretation that says that, given
  32.  
  33. >    int a [5][5];
  34.  
  35. >the access "a [1][6]" is illegal, because it goes past the bounds of the
  36. >array "a [1]". In other words, the declared type of the array does
  37. >restrict what can happen to a pointer derived from it.
  38.  
  39. Correct, but:
  40.  
  41.     int a[5][5]; int*p;
  42.  
  43.     p=a[1]+5;
  44.  
  45.     printf("a[2][0]=a[1][6]=%d\n",*++p);
  46.  
  47. sure seems to be allowed (although not recommended).
  48. -- 
  49. Sincerely,                                  berg@pool.informatik.rwth-aachen.de
  50.            Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de
  51.  
  52. "And now for something *completely* different!"
  53.