home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / fortran / 4748 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.2 KB  |  46 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^2: Help With Named common blocks...again
  5. Message-ID: <1992Dec15.204935.1@slacvx.slac.stanford.edu>
  6. Lines: 33
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <jumper.724475994@garfield.catt.ncsu.edu>
  10. Distribution: comp
  11. Date: Wed, 16 Dec 1992 04:49:35 GMT
  12.  
  13. Thanks, Michael, for prviding the additional information:
  14.  
  15. In article <jumper.724475994@garfield.catt.ncsu.edu>, jumper@garfield.catt.ncsu.edu (Michael Lanham) writes:
  16. [...]
  17. > Now I find in a file separate from the data file (the first one to declare what
  18. > SHARE1 is like) a use of SHARE1 entirely different.  This is in the first
  19. > SUBROUTINE in this src file that uses SHARE1 and every other routine that uses
  20. > SHARE1 in this file also follows the convention below. 
  21.  
  22. [...]
  23.  
  24. > My original question still stands.  Since these declarations are not the same
  25. > length nor (obviously) the same size arrays, is the second set of definitions
  26. > concatenated to the first?  Or, because they are in separate files, and
  27. > because in the second file(the odd man out file) the first declaration of
  28. > SHARE1 is _not_ like the datafile definition, they are pointing to the same
  29. > address space(ie TABLE(1) = NSVT(1) and OSVT(1) = TABLE(1001)
  30.                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  31.     This latter is the case (evidently I was correct in my original 
  32. followup...just lucky I guess :-).  Since the named common appears only
  33. once in each program section, the second varient you encountered refers
  34. to the same storage locations as the first varient, but with different
  35. names and, possibly, data types.  That is, it is as if the second version 
  36. were a alternative MAP within a UNION.  To the extent you can, verify that
  37. this is the intended behaviour.
  38.  
  39.     -Ken
  40. -- 
  41.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  42.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  43.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  44.  ----------------------------------------------------------------------------
  45.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  46.