home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17024 < prev    next >
Encoding:
Text File  |  1992-11-22  |  2.6 KB  |  65 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!uunet.ca!wildcan!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Re: Is this ANSI?
  5. Message-ID: <1992Nov23.090611.3209@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <24238@alice.att.com> <1992Nov21.125038.26244@sq.sq.com> <24270@alice.att.com>
  8. Date: Mon, 23 Nov 92 09:06:11 GMT
  9. Lines: 54
  10.  
  11. Andrew and I have been crossing postings; the one I'm responding to
  12. now contains a wrong prediction of what I would say in my previous
  13. posting.  I'll just address that point.
  14.  
  15. >     Unless both the pointer operand and the result point to
  16. >     elements of the same array object, or the pointer
  17. >     operand points one past the last element of an array
  18. >     object and the result points to an element of the same
  19. >     array object, the behavior is undefined if the result
  20. >     is used as an operand of the unary * operator.
  21. >
  22. > Now, look back at the assertion I asked you to remember.  I expect
  23. > that Mark Brader is going to say `But p->data isn't an array of
  24. > one element, it's an array of 101 elements.  After all, when you
  25. > said malloc(sizeof(struct FM + 100), you allocated enough memory
  26. > for 101 elements!'
  27.  
  28. No, I'm not.  That would be wrong for the reasons you said.  What I
  29. did say was that while the character pointed to by the decayed
  30. pointer p->data is indeed part of the one-character array p->data,
  31. it is *also* part of a larger array, namely the object returned by
  32. malloc(), whose size might be, say, 104 elements when considered
  33. as an array of char.  Therefore the Unless clause is applicable
  34. and the reference valid.
  35.  
  36. >         struct FM *q = (struct FM *) malloc(sizeof(struct FM) + 100);
  37. >        ... 
  38. >         *p = *q;
  39.  
  40. Agreed, this should not copy the 100 extra bytes.
  41.  
  42. > Another way to look at it is this.  Suppose I have a compiler that rejects:
  43. > 
  44. >     void f(struct FM *p)
  45. >     {
  46. >         p->data[5] = '?';
  47. >     }
  48.  
  49. Then, as they say,"your compiler is broken, and you should ask for a
  50. refund".  This is Yet Another Way in which C's very general pointer
  51. types inhibit the compiler from doing things that you might like it to.
  52.  
  53. Of course, your system is free to abort at *run* time in f(), if it
  54. finds that the argument passed to f() was merely a pointer to a
  55. struct FM, and not to a larger malloc()ed area.  Saber-C, or whatever
  56. they call it these days, would get this right.
  57. -- 
  58. Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
  59.     A standard is established on sure bases, not capriciously but with
  60.     the surety of something intentional and of a logic controlled by
  61.     analysis and experiment. ... A standard is necessary for order
  62.     in human effort.                -- Le Corbusier
  63.  
  64. This article is in the public domain.
  65.