From: analyst41 on
On Jul 11, 10:27 am, dpb <n...(a)non.net> wrote:
> Gordon Sande wrote:
> > On 2010-07-11 10:08:21 -0300, dpb <n...(a)non.net> said:
>
> ...
>
> >> "Any common block name (or blank common) can appear more than once in
> >> one or more COMMON statements in a program unit. The list following
> >> each successive appearance of the same common block name is treated as
> >> a continuation of the list for the block associated with that name. "
>
> >> Above from CVF documentation, not the Standard, but it is conforming
> >> behavior if not the exact wording.
>
> > Except all the various references to the common block named name1 should
> > be of the same size. Not enforcing this is a common extension.
>
> To clarify, the _TOTAL_ length of the named common entity must be the
> same in different program units but the references _within_ a given
> program unit of pieces comprising the whole is not an extension nor does
> it violate Standard.
>
> Given that the requirement for consistency in size is across different
> program units I'm sure it's not required to be diagnosed altho linker
> maps will be able to see mismatches and program units compiled together
> or compilers with facility for extended range analysis can as well.
>
> But, the code posted is perfectly legal and not any extension.
>
> Now, if it had been
>
> common /name1/var1,var2
> common /name1/var3,var4,var5
>
> in subprogram A and
>
> common /name1/var1,var2
> common /name2/var3,var4,var5
>
> in subprogram B, then indeed, "Houston.  We have a problem."
>
> --

It was

common /name1/var1,var2 everywhere except one sub-program where it was

common /name1/var1,var2
common /name1/var3,var4,var5

And it compiles just fine. The compiler does warn in cases like


common /name1/var1

and

common /name1/var1,var2

in two different sub-programs.

"In all program units, named common blocks with the name 'name1' must
have the same size."

Why was an exception made for common?

It is a fatal error to define the rank of an array more than once

dimension a(100)
dimension a(50)

in the same sub-program.





From: dpb on
Gordon Sande wrote:
....

> There will only be one reference to a common block within a probram unit
> even if the reference is the result of several statements with several
> lexographic occuurrances of the name because of the use of the
> concatenation feature of the syntax for commons.

Isn't that what I said (via the quote from the CVF doc's)??? :)

>> Given that the requirement for consistency in size is across different
>> program units I'm sure it's not required to be diagnosed altho linker
>> maps will be able to see mismatches and program units compiled
>> together or compilers with facility for extended range analysis can as
>> well.
>
> Very few linkers notice with some taking the longest and others the
> first reference to the named common.

What I was referring to was the map will have the length of each
compiled unit reference -- didn't say it would do anything automagically
to inform one of mismatches, only that one can find them if one looks.

--
From: dpb on
analyst41(a)hotmail.com wrote:
....

> It was
>
> common /name1/var1,var2 everywhere except one sub-program where it was
>
> common /name1/var1,var2
> common /name1/var3,var4,var5
>
> And it compiles just fine. The compiler does warn in cases like

Yes, the second statement simply extends the named common NAME1 just as
if it had been written as

common /name1/ var1,var2,var3,var4,var5

That is clearly no problem within the particular subprogram and the two
forms are syntactically identical and allowed.

> common /name1/var1
>
> and
>
> common /name1/var1,var2
>
> in two different sub-programs.
>
> "In all program units, named common blocks with the name 'name1' must
> have the same size."
>
> Why was an exception made for common?
>
> It is a fatal error to define the rank of an array more than once
>
> dimension a(100)
> dimension a(50)
>
> in the same sub-program.
....

That COMMON allows for there to be multiple statements defining the
total size of the block was done I presume simply for programming
convenience given the nature of COMMON being one of memory association
between other named entities (variables/arrays).

Arrays, otoh, are a single entity of a specific size.

--
From: analyst41 on
On Jul 11, 10:58 am, dpb <n...(a)non.net> wrote:
> analys...(a)hotmail.com wrote:
>
> ...
>
> > It was
>
> > common /name1/var1,var2 everywhere except one sub-program where it was
>
> > common /name1/var1,var2
> > common /name1/var3,var4,var5
>
> > And it compiles just fine.  The compiler does warn in cases like
>
> Yes, the second statement simply extends the named common NAME1 just as
> if it had been written as
>
> common /name1/ var1,var2,var3,var4,var5
>

and that ought to generate a size mismatch warning from the compiler
and for some reason it doesn't happen.


> That is clearly no problem within the particular subprogram and the two
> forms are syntactically identical and allowed.
>
>
>
>
>
> > common /name1/var1
>
> > and
>
> > common /name1/var1,var2
>
> > in two different sub-programs.
>
> > "In all program units, named common blocks with the name 'name1' must
> > have the same size."
>
> > Why was an exception made for common?
>
> > It is a fatal error to define the rank of an array more than once
>
> > dimension a(100)
> > dimension a(50)
>
> > in the same sub-program.
>
> ...
>
> That COMMON allows for there to be multiple statements defining the
> total size of the block was done I presume simply for programming
> convenience given the nature of COMMON being one of memory association
> between other named entities (variables/arrays).
>
> Arrays, otoh, are a single entity of a specific size.
>
> --- Hide quoted text -
>
> - Show quoted text -

From: mecej4 on
analyst41(a)hotmail.com wrote:

> I have been running code foreever that had
>
> common /name1/var1,var2
> common /name1/var3,var4,var5
> in the same sub-program.

A common block can be declared in pieces. Your two pieces are equivalent to

common /name1/var1,var2,var3,var4,var5

>
> The intent was, of course, to call the second common /name2/.
>
> I corrected it and the results are still the same, because
> var3,var4,var5 occur only in that sub-program (I haven't gotten round
> to doing whatever I was planning to do with var3-5.)
>
> Why doesn't the compiler (Lahey) flag this as an error or at least as
> a warning?

There is no reason to, since a many-piece COMMON statement is allowed, even
it it is not commonly used.

-- mecej4