I think it is non-standard. section 12.4.1.5, restrictions on dummy
arguments not present says
"an optional dummy argument that is not present...
shall not be referenced or defined."
To me, that clearly prevents it from being used as an I/O
inquiry spec if it is not present.
There are exceptions allowing it to be passed on as an actual
argument to an optional dummy. But I don't see anything
that says I/O INQUIRY SPECIFIERS are "dummy arguments".
I think there was an interpretation a few years ago about using
optional arguments in intrinsics, things like
sum(a, mask = optional_dummy_arg >0)
and what happens if the optional_dummy_argument is not present.
My recollection is that the function must not be executed if
the optional arg is not actually present. I think the words in
12.4.1.5 try to say that. At least, that's what I remember.
Dick Hendrickson
Van Snyder 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.
>
> Do you know the answer?
>
> Best regards,
> Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|