home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / std / c / 2569 < prev    next >
Encoding:
Text File  |  1992-09-03  |  1.5 KB  |  31 lines

  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!usc!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watmath!thinkage!dat
  3. From: dat@thinkage.on.ca (David Adrien Tanguay)
  4. Subject: struct hack, was Re: strcpy implementation question
  5. Message-ID: <1992Sep4.015335.3612@thinkage.on.ca>
  6. Organization: Thinkage, Ltd.
  7. References: <9209030426.AA24169@enet-gw.pa.dec.com>
  8. Date: Fri, 4 Sep 1992 01:53:35 GMT
  9. Lines: 20
  10.  
  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
  14. >>that prevents the compiler from performing bounds checking on accesses to
  15. >>name.
  16. >
  17. >Uh, nothing except the standard's definitions of [], unary *, and binary +
  18. >operators.  :-R rhetoric.
  19. >Bounds checking is not allowed to affect output of a valid but ugly program.
  20.  
  21. Could you flesh this argument out? I had the impression that the last time
  22. it came up here the conclusion was that this trick was not sanctioned
  23. (i.e., a bounds checker could fail). After all, 3.3.6 "Additive Operators"
  24. says that you aren't guaranteed to go past the end of an array object,
  25. so if you start with the trailing array (in the struct) you can't go past
  26. its end. (You could if you used a different "handle" for the malloc return
  27. value.)
  28. -- 
  29. David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
  30. Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
  31.