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