home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / fortran / 4728 < prev    next >
Encoding:
Text File  |  1992-12-15  |  3.5 KB  |  80 lines

  1. Path: sparky!uunet!timbuk.cray.com!shamash!ems!ems.cdc.com!mstemper
  2. From: mstemper@ems.cdc.com (Michael Stemper)
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: Need help with named common blocks
  5. Message-ID: <31152@nntp_server.ems.cdc.com>
  6. Date: 15 Dec 92 18:35:03 GMT
  7. References: <jumper.724304615@fritz.catt.ncsu.edu> <1992Dec13.211623.1@slacvx.slac.stanford.edu>
  8. Sender: sys@ems.ems.cdc.com
  9. Reply-To: mstemper@ems.cdc.com
  10. Organization: Empros Systems International, a division of Ceridian
  11. Lines: 66
  12. Nntp-Posting-Host: kirk.ems.cdc.com
  13.  
  14. In article <1992Dec13.211623.1@slacvx.slac.stanford.edu>, fairfield@slacvx.slac.stanford.edu writes:
  15. >In article <jumper.724304615@fritz.catt.ncsu.edu>, jumper@fritz.catt.ncsu.edu (Michael Lanham) writes:
  16.  
  17. >> I have several program src files.  In the file with the BLOCK DATA segment,
  18. >> the COMMON block is named and shaped as follows:
  19.  
  20. >>       COMMON/SHARE1/TABLE(1770),NOPU(54),FLHS(54),UNUSE0(122),
  21. ...
  22. >>      -           LISTX(61),INTERX(70),SYNTAB(2,26),CHARX(26),TAG(50),
  23. >>      -           (50)
  24.  
  25. >> Now I found an additional SHARE1 that is different.
  26.                ********************
  27.  
  28. >>       COMMON/SHARE1/NSVT(1000),OSVT(1000),
  29. ...
  30. >>      -             OUTTAB(50,4),SUPP(100,2),SYMBL(2),UNUSE2(18)
  31.  
  32. >> Is an accurate way of thinking of SHARE1 is the first declaration plus the
  33. >> second concatenated to the end of the second?  I need to know this so I can
  34. >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  35.  
  36. >    No.  In FORTRAN, the named common is a single storage area.  A mis-feature
  37. >of FORTRAN is that common blocks may be declared differently in different
  38. >program sections, but each still refers to the same storage area.  Thus, in
  39. >the example above, NSVT(1) is the same storage location as TABLE(1), etc.
  40.  
  41. Assuming that Mr. Lanham's words "an additional SHARE1" mean that the
  42. module in question had both declarations, then his guess was right, the
  43. two definitions are concatenated. However, only this module has access
  44. to the additional items (unless somebdoy did something really ugly, like
  45. accessing TAG out of bounds to get at the extras).
  46.  
  47. If the module only had this new declaration, then your reasoning follows.
  48.  
  49. >of type CHARACTER*1 (or BYTE or INTEGER*1 or LOGICAL*1)...  The point is
  50. >that most compilers allow the total length of a common to be different in
  51. >different program sections.  Some will (nicely) take the longest declared
  52. >length as the total, others (not so nice) will take the _last_ declared
  53. >length.
  54.  
  55. Assuming each module is separately compiled, there is absolutely nothing
  56. that a compiler can do to prevent different modules from having different
  57. lengths for the same COMMON block. However, as you point out, a common
  58. block is a single storage area. The loader must figure out how much space
  59. to allocate for it.
  60.  
  61. The strategy that I am most familiar with is the first time a loader
  62. encounters a COMMON block, it will reserve as much space as the module
  63. referencing it requests. If modules loaded later think that the block
  64. is shorter, there is no problem. If one of them thinks it is longer,
  65. you are S.O.L. If the loader is friendly, it will give you a fatal
  66. error message. Otherwise, it won't detect the problem and you will
  67. end up overwriting the beginning of another COMMON block (or worse
  68. yet, code!).
  69.  
  70. >    In any case, you may want to investigate how /SHARE1/ is being used in
  71. >the odd-man-out routine to be sure it's not an out-and-out error...
  72.  
  73. ABSOLUTELY!!!
  74.  
  75. -- 
  76. #include <Standard_Disclaimer.h>
  77. Michael F. Stemper
  78. Power Systems Consultant
  79. mstemper@ems.cdc.com
  80.