|
|
 |
 |
 |
 |
Fortran Programming Language
|
 |
 |
 |
 |
 |
 |
 |
 |
MAX and optional arguments
From a bug filed in the GCC tracking system, I have come to question what is the standard-expected behaviour for MAX when it is passed optional arguments. For example, please consider the following code: program test print *, m1(1,2,3,4) print *, m1(1,2,3) print *, m1(1,2) print *, m1(1) print *, m1() contains integer function m1(a1,a2,a3,a4) integer, optional :: a1,a2,a3,a4 m1 = max(a1,a2,a3,a4) end function m1 end What is the expected output? The F2003 standard (draft) actually isn't very clear about the arguments to MAX, to say the least (or, if it is clear, I didn't find the right place). My own understanding of how this works is that the first three print statements should output 4, 3, 2 and 1 respectively, while the last one is actually not valid code. If that reading is true, what do you think of the following modified code? program test print *, m1(3,4) print *, m1(3) print *, m1() contains integer function m1(a1,a2) integer, optional :: a1,a2 m1 = max(a1, a2, 1, 2) end function m1 end Should it print 4, 3 and 2? Or is each call to m1() illegal, because the standard seems to assume that the first arguments to MAX have a special status, and should not be missing? Sorry for the long post, and thanks for your light on that question. -- FX
"FX" <coud @alussinan.org> wrote in message news:f2sepq$1qbg$1@nef.ens.fr... > My own understanding of how this works is that the first three print > statements should output 4, 3, 2 and 1 respectively, while the last one > is actually not valid code. If that reading is true, what do you think of > the following modified code?
I think the last two are invalid code, as the standard requires two present arguments. > Should it print 4, 3 and 2? Or is each call to m1() illegal, because the > standard seems to assume that the first arguments to MAX have a special > status, and should not be missing?
The calls to m1 are all legal, but references to MAX that cause it to not have two leading present arguments are not. In f95 12.4.1.5 we also read "A dummy argument is present in an instance of a subprogram [i.e. MAX] if it is associated with an actual argument [i.e. a1] and the actual argument is [...] a dummy argument that is present in the invoking subprogram [i.e. m1] ...". Anyway, that's my reading. Regards, Mike Metcalf
FX wrote: > From a bug filed in the GCC tracking system, I have come to question what > is the standard-expected behaviour for MAX when it is passed optional > arguments. For example, please consider the following code: > program test > print *, m1(1,2,3,4) > print *, m1(1,2,3) > print *, m1(1,2) > print *, m1(1) > print *, m1() > contains > integer function m1(a1,a2,a3,a4) > integer, optional :: a1,a2,a3,a4 > m1 = max(a1,a2,a3,a4) > end function m1 > end > What is the expected output? The F2003 standard (draft) actually isn't > very clear about the arguments to MAX, to say the least (or, if it is > clear, I didn't find the right place). > My own understanding of how this works is that the first three print > statements should output 4, 3, 2 and 1 respectively, while the last one > is actually not valid code. If that reading is true, what do you think of > the following modified code? > program test > print *, m1(3,4) > print *, m1(3) > print *, m1() > contains > integer function m1(a1,a2) > integer, optional :: a1,a2 > m1 = max(a1, a2, 1, 2) > end function m1 > end > Should it print 4, 3 and 2? Or is each call to m1() illegal, because the > standard seems to assume that the first arguments to MAX have a special > status, and should not be missing? > Sorry for the long post, and thanks for your light on that question.
The codes are non-standard, at least that's the way I'd read it. The header for MAX is MAX( a1, a2, [a3,...]) which clearly (?) means that the first two arguments, a1 and a2, are required to be there. The section on optional dummy arguments (like your a1 and a2) says "12.4.1.6 Restrictions on dummy arguments not present ... An optional dummy argument that is not present is subject to the following restrictions: ... (4) It shall not be supplied as an actual argument corresponding to a nonoptional dummy argument" So, you can't pass a not-present optional dummy argument as an actual argument to a not-optional dummy argument. This is one of the run-time errors that compilers aren't required to detect. Personally, I'd expect them to issue a run-time abort if either a1 or a2 in not present. Dick Hendrickson
|
 |
 |
 |
 |
|