home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / mswindo / programm / misc / 4638 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.3 KB  |  84 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!mcsun!sunic!kth.se!dront.nada.kth.se!d88-jwa
  3. From: d88-jwa@dront.nada.kth.se (Jon WΣtte)
  4. Subject: Re: difference between STUFF *stuff & STUFF stuff[]???
  5. Message-ID: <1993Jan6.151741.29382@kth.se>
  6. Sender: usenet@kth.se (Usenet)
  7. Nntp-Posting-Host: dront.nada.kth.se
  8. Organization: Royal Institute of Technology, Stockholm, Sweden
  9. References: <1993Jan6.084522.25921@emr1.emr.ca>
  10. Date: Wed, 6 Jan 1993 15:17:41 GMT
  11. Lines: 71
  12.  
  13. In <1993Jan6.084522.25921@emr1.emr.ca> jagrant@emr1.emr.ca (John Grant) writes:
  14.  
  15. >            static STUFF stufftable[MAXSTUFF];
  16. >   and in another module that referenced it:
  17. >            extern STUFF stufftable[];
  18. >Ok, that was fine and everything worked ok.
  19.  
  20. I'm not sure that it should. Since stufftable is explicitly
  21. static to a module (file) you shouldn't have gotten at it
  22. from anywhere else. If you did, that's a bug.
  23.  
  24. >            static STUFF *stufftable;
  25. >            stufftable=malloc(MAXSTUFF*sizeof(STUFF));
  26. >and in the other module, I left it as:
  27. >            extern STUFF stufftable[];
  28.  
  29. This of course is totally bogus. It tells the compiler that
  30. you have a data area consisting of items, and that saying
  31. "stufftable" will generate the address of that data area.
  32.  
  33. >            extern STUFF *stufftable;
  34. >and re-built, it ran perfectly.
  35.  
  36. Well, this is the correct thing, saying there's this variable
  37. stufftable pointing to data items, and saying "stufftable"
  38. gives you the contents of that variable.
  39.  
  40. However, since stufftable is static in the first module, you
  41. should not have been able to get at it; the linker should
  42. have given you an unresolved external error.
  43.  
  44. >and explain why it is so dangerous here, but it's perfectly ok
  45. >to use a pointer or a [] in a function declaration.
  46.  
  47. I did, above. Better yet, buy Kernighan & Ritchie,
  48. "The C Programming Language" which explain this and a lot
  49. of other things about C.
  50.  
  51. One common and recommended way of avoiding this kind of
  52. problems is to have the extern declaration in a header,
  53. that both the defining and using file uses.
  54.  
  55. foo.h:
  56.  
  57. extern fooItem * fooPointer ;
  58.  
  59.  
  60. foo.c:
  61.  
  62. #include "foo.h"
  63.  
  64. fooItem * fooPointer = NULL ;
  65.  
  66. void
  67. InitFoo ( void )
  68. {
  69.     fooPointer = ( fooItem * ) calloc ( sizeof ( fooItem ) , 47 ) ;
  70. }
  71.  
  72.  
  73. bar.c:
  74.  
  75. #include "foo.h"
  76.  
  77. ...
  78.     fooPointer [ 4 ] = ...
  79.  
  80. -- 
  81.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  82.  
  83.    Cookie Jar: Vanilla Yoghurt with Crushed Oreos.
  84.