home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / 19063 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  2.9 KB
  1. Xref: sparky comp.sys.sgi:19063 comp.sys.sgi.apps:101
  2. Path: sparky!uunet!olivea!sgigate!odin!sgihub!zola!arthur
  3. From: arthur@sgi.com (Arthur Evans)
  4. Newsgroups: comp.sys.sgi,comp.sys.sgi.apps
  5. Subject: Re: help with IPC
  6. Message-ID: <v7egfpc@zola.esd.sgi.com>
  7. Date: 23 Jan 93 02:29:51 GMT
  8. References: <1993Jan14.002814.11411@eos.arc.nasa.gov> <uslbhsg@zola.esd.sgi.com> <1jkqu9INNqf8@news.cerf.net>
  9. Sender: news@zola.esd.sgi.com (Net News)
  10. Reply-To: arthur@chiba.esd.sgi.com (Arthur Evans)
  11. Organization: Silicon Graphics, Inc.
  12. Lines: 60
  13.  
  14.  
  15. In article <1jkqu9INNqf8@news.cerf.net> pete@ent-img.com writes:
  16. >In article <uslbhsg@zola.esd.sgi.com> arthur@chiba.esd.sgi.com (Arthur Evans) writes:
  17. >>This works because msgbuf and msgbuf1 are essentially
  18. >>the same structure.  Both consist of a long and a char 
  19. >>pointer (that is, an array of char).  
  20. >NO NO NO - This is a common misconception which K&R unwittingly
  21. >lead people into, since you can pass an array name as if it were
  22. >a pointer to char, but a char pointer and an array of char are NOT
  23. >the same thing at all.
  24.  
  25. You're right, of course.  I knew there was some
  26. reason that the example code in question would work 
  27. (at least before ANSI) but I clearly wasn't thinking
  28. too hard when I tried to explain it.
  29.  
  30. >You aren't alone with this misconception - K&R's explanation leaves
  31. >a lot to your imagination (or prior knowledge).
  32. >The name of an array of char has the syntactic type of "pointer to char"
  33. >in most contexts (but not the same semantics at all - try sizeof() on
  34. >both and see what you get)...  This particular struct really does use the
  35. >"array of char" meaning.
  36. >
  37. >>Now, it's a mystery to me why mtext is declared as
  38. >>char mtext[1] in the header file, as opposed to 
  39. >>char *mtext, but I suppose there's some good reason
  40. >>for it (like everything else in UNIX ;-).
  41. >This is because the array is itself IN THE STRUCTURE, not in remote
  42. >memory pointed to from the structure.  
  43.  [  ... ]
  44.  
  45. Alright, now I feel stupid.  Someone explained this to
  46. me once, and I had the vauge unsettling feeling while
  47. I was posting the article that I should *know* why 
  48. mtext was declared that way.
  49.  
  50. In light of this, a better answer to the original question
  51. would be that the example program should be rewritten 
  52. such that it dynamically allocates space for the msgbuf
  53. structures, with the appropriate amount of added space
  54. for the message text.
  55.  
  56. >>By the way, if you have any other comments about the 
  57. >>IRIX Programming Guide, please forward them to me,
  58. >>arthur@esd.sgi.com--I'm in charge of revising this
  59. >>book for IRIX 5.0.  [ ... ] Any thoughts on what 
  60. >>could use more or less coverage in a new version of this
  61. >>book would also be welcome.
  62. >Well, please talk to a programmer who understands the reasons
  63. >behind some of these kluges (yes, they are kluges) before writing
  64. >it up.  
  65.  
  66. I assure you that the manual will receive both more thought
  67. and more review that my average netnews posting ;-).
  68.  
  69. Anyway, thanks for keeping me honest.
  70.  
  71. >-- Pete
  72.  
  73. -arthur
  74.