home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / fortran / 4701 < prev    next >
Encoding:
Text File  |  1992-12-14  |  3.0 KB  |  64 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!stanford.edu!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: Need help with named common blocks
  5. Message-ID: <1992Dec13.211623.1@slacvx.slac.stanford.edu>
  6. Lines: 51
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <jumper.724304615@fritz.catt.ncsu.edu>
  10. Distribution: comp
  11. Date: Mon, 14 Dec 1992 05:16:23 GMT
  12.  
  13. In article <jumper.724304615@fritz.catt.ncsu.edu>, jumper@fritz.catt.ncsu.edu (Michael Lanham) writes:
  14. [...]
  15. > I have several program src files.  In the file with the BLOCK DATA segment,
  16. > the COMMON block is named and shaped as follows:
  17. > 
  18. >       IMPLICIT INTEGER (A-Z)
  19. >       COMMON/SHARE1/TABLE(1770),NOPU(54),FLHS(54),UNUSE0(122),
  20. >      -           XLATE(127),KWT1(50),KWT2(50),STACK1(50),STACK2(50),
  21. >      -           SYMBOL(8),VALUE(8),UNUSE5(16),CHAR(80),VALUXY(12),
  22. >      -           LISTX(61),INTERX(70),SYNTAB(2,26),CHARX(26),TAG(50),
  23. >      -           (50)
  24. > 
  25. > 
  26. > 
  27. > In most of the other modules the common block share1 is entered the same way.
  28. > Now I found an additional SHARE1 that is different.
  29. > 
  30. >       COMMON/SHARE1/NSVT(1000),OSVT(1000),
  31. >      -             OPND(3),LINE(133),UNUSE3(574),
  32. >      -             OUTTAB(50,4),SUPP(100,2),SYMBL(2),UNUSE2(18)
  33. > 
  34. > Is an accurate way of thinking of SHARE1 is the first declaration plus the
  35. > second concatenated to the end of the second?  I need to know this so I can
  36.          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  37. > correctly build my union in C to accurately reflect the SHARE1 structure.
  38.  
  39.     No.  In FORTRAN, the named common is a single storage area.  A mis-feature
  40. of FORTRAN is that common blocks may be declared differently in different
  41. program sections, but each still refers to the same storage area.  Thus, in
  42. the example above, NSVT(1) is the same storage location as TABLE(1), etc.
  43.  
  44.     Note that the first declaration makes COMMON/SHARE1/ 3130 4-byte integers
  45. long (barring other declaration following, and inacurracies in my arithmetic),
  46. while the second declaration is only 2710 long.  Well, that's probably 
  47. unlikely since something like CHAR(80) is most likely declared later to be
  48. of type CHARACTER*1 (or BYTE or INTEGER*1 or LOGICAL*1)...  The point is
  49. that most compilers allow the total length of a common to be different in
  50. different program sections.  Some will (nicely) take the longest declared
  51. length as the total, others (not so nice) will take the _last_ declared
  52. length.
  53.  
  54.     In any case, you may want to investigate how /SHARE1/ is being used in
  55. the odd-man-out routine to be sure it's not an out-and-out error...
  56.  
  57.         Cheers, Ken
  58. -- 
  59.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  60.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  61.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  62.  ----------------------------------------------------------------------------
  63.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  64.