Dear Van:
IMHO, Phil's compiler is standard conforming and yours is not.
I just checked the F95 standard. In section 9.4.1, rule R912 says in
part[144:27,34],
R912 io-control-spec is [UNIT=} io-unit
. . .
or ADVANCE=scalar-default-char-expr
There are no constraints, either after this rule or anywhere else in chapter 9
which prohibit any value of an I/O keyword from either having the OPTIONAL
attribute or, if it does, requiring it to be present. However, the general
rules for BNF syntax descriptions specifies that optional values are enclosed in
brackets, [], (see section 1.6.2, list item (3), [4:34-5:7]). since the
scalar-default-char-expr for the ADVANCE= specifier is not enclosed in brackets,
it is required to be present.
The scalar-default-char-expr can only take one of two values: YES or NO.
This is clearly stated by the first sentence [147:34] of section 9.4.1.8, "The
scalar-default-char-expr shall evaluate to YES or NO." thus, any other
alternative values of the scalar-default-char-expr are invalid. These would
include a null string, "", a string of all blanks, " ", or some other string,
e.g., "VAN_SNYDER".
This looks like a good interpretation issue. Perhaps one of us should write
this up and submit it as an official interpretation.
As one form of proposed response, what do others think of creating a sort of
super-constraint for all of chapter 9 which would prohibit the OPTIONAL
attribute for the right hand sides of all I/O keywords? This certainly is
checkable at compile time.
Van Snyder wrote:
> I wrote:
>
> > > One of my compilers was perfectly happy to accept an optional dummy
> > > argument as an I/O specifier, viz. "advance=adv", where "adv" was
> > > an optional dummy argument.
> > >
> > > Furthermore, if the actual argument associated with "adv" was not
> > > present, the run-time was perfectly happy to pretend I hadn't
> > > specified "advance=".
> > >
> > > I found this to be rather elegant, but I suspect it isn't standard-
> > > conforming behavior. The section on I/O statements is quite large,
> > > however, so I'm not sure whether there's something therein that defines
> > > specifier values or variables to behave like actual arguments associated
> > > with optional dummy arguments, and I missed it, or there's nothing
> > > there.
>
> And Philip Helbig wrote the following, which is what I expected to be
> the case. Does anybody know, by studying a standard, which behavior is
> standard-conforming? I suspect Philip's compiler is standard conforming,
> and mine isn't. (But it would be cool if it were the other way around!)
>
> > PROGRAM TEST
> > PRINT*, 'YES' ! works as expected
> > CALL TEST_ADV("YES")
> > PRINT*
> > PRINT*, 'NO' ! works as expected
> > CALL TEST_ADV("NO")
> > PRINT*
> > !PRINT*, 'NOTHING' ! causes access violation and crashes
> > !CALL TEST_ADV()
> > !PRINT*
> > !PRINT*, 'NOTHING' ! causes access violation and crashes
> > !CALL TEST_ADV
> > !PRINT*
> > !PRINT*, 'INVALID' ! gives "%FOR-F-INVARGFOR, invalid argument
> > ! to FORTRAN Run-Time Library" and crashes
> > !CALL TEST_ADV("VAN_SNYDER")
> > END
> > SUBROUTINE TEST_ADV(ADV)
> > CHARACTER (LEN=*), OPTIONAL, INTENT(IN) :: ADV
> > WRITE (*,'(T2,A)',ADVANCE=ADV) "first"
> > WRITE (*,'(TR1,A)',ADVANCE="YES") "second"
> > END
--
----------
Sincerely,
Craig T. Dedo Internet:
[log in to unmask]
Elmbrook Computer Services Voice Phone: (262) 783-5869
17130 W. Burleigh Place Fax Phone: (262) 783-5928
Brookfield, WI 53005-2759 Disclaimer: These opinions are
mine alone.
USA They do NOT
represent any organization.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
