This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Query abt Allocatable Dummy argument in F2003
On Aug 8, 2005, at 1:14 AM, Sudesh Chandna, Noida wrote:
Standard says " Interface must be explicit if dummy argument is
allocatable. I.e. either corresponding procedure/function is internal
or interface is given explicitly if its external". My question is:
Above constraint should be be taken care by user or compiler ?
First, please note that this is not a constraint as the term is used in
Fortran. The term "constraint" is used with specific meaning in the
Fortran standard. Use in its broader English meaning should therefore
be avoided or confusions and errors will result. The constraints in
f90/f95/f2003 are all explicitly annotated in the standard with the
word "constraint"; in F2003 they also have constraint numbers for handy
reference. We usually use terms like "requirement" or "restriction" to
refer to the other provisions of the standard - almost any word other
than "constraint". The general English meaning of "constraint" fits,
but it causes confusion when used that way in context of the Fortran
standard. There are several other similar English words with specific
technical meaning in the Fortran standard. The term "reference" comes
to mind. The standard requires compilers to be able to diagnose
constraints (item 3 in section 1.5 of f2003), but that specifically
means the things annotated as constraints - not all the other material
of the standard. See section 1.7.3 of f2003.
Second. The question of whether the compiler or the user is responsible
for something is fundamental to many aspects of the standard. Often a
requirement can have exactly opposite meanings depending on whether it
is a requirement on the user or on the compiler. It is therefore
absolutely critical to keep the first paragraph of 1.7 in mind. That
apparently bland and innocuous-looking paragraph is critical to
understanding the whole standard. Note in particular the part that says
"Except where stated otherwise, such requirements and prohibitions
apply to programs rather than processors."
The requirement that a processor be able to diagnose constraint
violations states that it is a requirement on the processor. But the
large majority of the requirements in the standard do not - that
includes the one you are asking about.
Third, your "i.e." conclusion above is incorrect in several regards.
Most notably, you seem to be classifying procedures as either internal
or external. That is not a correct division; it neglects module and
intrinsic procedures. The omission is notable in that I personally
recommend the use of module procedures for code that uses constructs
like this. The compiler has to be able to deal with all the cases, but
I recommend that users use module procedures, in which case they won;t
make errors like this. This is somewhat peripheral to your question,
but it has to be completely understood to have any hope of working on
implementation.
Also kindly note that same constraint is there for pointer attribute.
"Interface must be explicit if dummy argument has pointer attribute".
(Section 12.3.1.1) But Gfortran doesn't generate any error message if
interface is not given explicitly.
First, it is not a constraint. See above.
Second, there is a reason that it isn't a constraint. It is not
possible to diagnose this at compile time without throwing out separate
compilation of external procedures. That is because it is valid to pass
a pointer as an actual argument when the dummy is not a pointer. That
has the effect of passing the target of the pointer and it does not
require an explicit interface. The whole reason for requiring an
explicit interface is that the compiler won't in general know what is
intended unless there is an explicit interface to tell it.
Is this a bug in Gfortran ?
No. Nor is it even a poor quality of implementation. This is about what
would be expected from that particular error in most cases. Some
compilers *MIGHT* happen to detect the problem in some cases - most
notably if the call and the subroutine are in the same source file. But
that is not at all something you can count on; it constitutes a
compiler going "above and beyond the call of duty." Namely, it is
certainly a nice feature for a compiler, but more a "luxury" than part
of the basic expectations.
--
Richard Maine | Good judgment comes from experience;
Richard.Maine@nasa.gov | experience comes from bad judgment.
| -- Mark Twain