home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / std / c / 2570 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  1.7 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!hplabs!ucbvax!jit081.enet.dec.com!diamond
  2. From: diamond@jit081.enet.dec.com (04-Sep-1992 1639)
  3. Newsgroups: comp.std.c
  4. Subject: Re: struct hack, was Re: strcpy implementation question
  5. Message-ID: <9209040741.AA16120@enet-gw.pa.dec.com>
  6. Date: 4 Sep 92 07:41:41 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Lines: 23
  9.  
  10. In article <1992Sep4.015335.3612@thinkage.on.ca> dat@thinkage.on.ca (David Adrien Tanguay) writes:
  11. >diamond@jit081.enet.dec.com (03-Sep-1992 1325) writes:
  12. >>In article <PINKAS.92Sep2173635@skywalker.intel.com> pinkas@skywalker.intel.com (Israel Pinkas) writes:
  13. >>>The variable length struct is a hack.  There is nothing in the language that
  14. >>>prevents the compiler from performing bounds checking on accesses to name.
  15.  
  16. >>Uh, nothing except the standard's definitions of [], unary *, and binary +
  17. >>operators.  :-R rhetoric.
  18. >>Bounds checking is not allowed to affect output of a valid but ugly program.
  19.  
  20. >I had the impression that the last time it came up here the conclusion was
  21. >that this trick was not sanctioned[...]  3.3.6 "Additive Operators"
  22. >says that you aren't guaranteed to go past the end of an array object,
  23.  
  24. No (though it was the conclusion of some others) and yes, respectively.
  25. You can't go past the end of an array object.  But if malloc() or some other
  26. variable has defined the end of the actual array object, then the + operator
  27. can get you that far, regardless of the declared type that some other array
  28. variable had before getting flattened to a pointer.
  29. --
  30. Norman Diamond       diamond@jit081.enet.dec.com
  31. If this were the company's opinion, I wouldn't be allowed to post it.
  32. "Yeah -- bad wiring.  That was probably it.  Very bad."
  33.