Re: Allocattable and namelist object

On Feb 14, 1:34 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
steve <kar...@xxxxxxxxxxx> wrote:
Someone has reported a bug against gfortran that suggests that
following code is legal Fortran 2003.

  PROGRAM MAIN
  REAL, DIMENSION(:), ALLOCATABLE :: TAB
  NAMELIST/TOTO/TAB
  END PROGRAM MAIN

Gfortran currently issues an error in accordance with a
constraint in Fortran 95:

   F95, Sec 5.4, p. 66

   Constraint:
   A namelist-group-object shall not be an array dummy
   argument with a nonconstant bound, a variable with
   nonconstant character length, an automatic object,
   a pointer, a variable of a type that has an ultimate
   component that is a pointer, or an allocatable array.

That seems pretty explicit, but I think we all agree on that.



In checking the Fortran 2003 standard, the above constraint
has been removed.  Further searching leads to two passages
that appear to be in conflict.

   F2003, Sec. 5.4, p. 95

   A namelist group object shall either be accessed by use
   or host association or shall have its type, type parameters,
   and shape specified by previous specification statements or
   the procedure heading in the same scoping unit or by the
   implicit typing rules in effect for the scoping unit.

   F2003, Sec. 9.5.3.6,

   Every allocatable namelist-group-object in the namelist group
   shall be allocated and every namelist-group-object that is a
   pointer shall be associated with a target.

The statement from Sec. 5.4 states that a "namelist group object
... shall have its type, type parameters, and shape specified
by previous specification statements".  In the above code, the
shape has not been specified prior to the namelist statement.
However, the statement from Sec. 9.5.3.6 suggests that an allocatable
array can be in a namelist object.

Are these statements in conflict or am I missing some other
part of the Fortran 2003 standard?

I'd probably interpret it as that the shape was specified prior to the
namelist statement. It was specified to be deferred shape. I'm not sure
that the wording is great; it strikes me as wording from the prior
standard that perhaps didn't get changed to reflect other changes. But I
can at least twist my mind to read it that way. No other reading makes
any sense to me at all, as it is just nonsense to say that any
allocatable arrays have to be allocated, but then also say that you
can't have allocatable arrays. The shape of an allocatable array can
never be specified in a specification statement to be anything other
than deferred.

Which is to say that I'd consider the code to be legal f2003, although
illegal f95, based on th eabove citations. (I was to lazy to actually
check your citations, but they seem plausible.)


Richard,

Thanks for the comment. I had not thought about such an
interpretation.

In the definition of a deferred-shaped array one finds:

5.1.2.5.3 Deferred-shape array

A deferred-shape array is an allocatable array or an
array pointer.

An allocatable array is an array that has the ALLOCATABLE
attribute and a specified rank, but its bounds, and hence
shape, are determined by allocation or argument association.

I would interpret this to mean that the deferred-shape array
does not have a specified shape in the code I posted. Hence,
the two statements in F2003 are contradictory.

The current draft of F2008 is even more convincing that there
is a problem. The language from Sec. 5.4 in the F95 and F2003
standards is idenitical to the language in F2008. F2003 however
has revised the definition of deferred-shape array to include

5.3.8.4 Deferred-shape array

3 The size, bounds, and shape of an unallocated allocatable
array or a disassociated array pointer are undefined.
No part of such an array shall be referenced or defined;
however, the array may appear as an argument to an
intrinsic inquiry function as specified in 13.1.

I guess I need to look into getting an official interpretation.

--
steve
.

Relevant Pages

  • Re: "Sorting" assignment
    ... If the array is already sorted, this means that you end up ... less time than a bubble sort, ...     int intLeft, ... I don't declare anything inside of a loop is why. ...
    (comp.programming)
  • Re: #defining an array within another in C language
    ... you do not know the number of elements of the array. ...     int var; ... C99 flexible array members or the plain old "struct hack". ...
    (comp.lang.c)
  • Re: Generic programming in C
    ... struct tag$ArrayInterface; ...     unsigned int Flags; ... specific type as the contents of the array. ...
    (comp.lang.c)
  • Re: Puppy Mastiff wants to Nip at Faces
    ... in my first college textbook on structured programming. ... they did was loop through an array to show how you could easily access ...   arrays and loops because it makes for less work. ...
    (rec.pets.dogs.behavior)
  • Re: please help with array and search!!!
    ...   ALLOCATE)) ... in the SUBROUTINE countall ... allocatable array at must have a deferred shape. ...
    (comp.lang.fortran)