Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Behavior of Inquire?

0 views
Skip to first unread message

gaurav

unread,
Feb 7, 2007, 11:34:41 PM2/7/07
to
hi,

What should be the behavior of Inquire statement on an unopened/
unconnected file?
What does standard says in this regard about the status of various
parameters like
formatted, unformatted if an we attempt to inquire an unopened file?

Thanks
Gaurav

Richard Maine

unread,
Feb 8, 2007, 12:26:47 AM2/8/07
to
gaurav <gauravg...@gmail.com> wrote:

That's too general a question to give an answer much shorter than just
copying the whole section on inquire. It says different things about
different inquiries. You really need to just read the description of
each specifier. I'm not going to copy every one here. But to give a
short version, for the most part, the connection status of the file is
irrelevant.

I assume, of course, that you are talking about inquire by file name.
There are several forms of inquire, but that's the only one where it
even makes sense to talk about an unconnected file. (You could inquire
about an unconnected unit, but that's not the same thing.)

However, just because the standard doesn't say much about the subject,
don't assume that means that there can't be a difference. Note that
"unknown" or something simillar, is an option for many of the
specifiers. It is quite plausible that the compiler might just say that
many things are unknown for an unconnected file.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

gaurav

unread,
Feb 8, 2007, 1:05:39 AM2/8/07
to
hi Richard,

Thanks for you reply. I ll try to be specific in what i want to know.
I want to know what should be the status of parameters FORMATTED and
UNFORMATTED when i am inquiring by file and file is not connected.

I read the standard ((ISO/IEC:1539-1:1997)) and could gather that
these two parameters should be UNKNOWN for this case.

Reasons:
1) (table C.6.5)
Value of FORMATTED is UNKNOWN if:
a) Inquire by file is done and file is not connected.
b) Inquire by Unit is done and file is not connected.

2) In (9.6)
"An INQUIRE statement may be executed before, while, or after a file
is connected to a unit. All values assigned by an INQUIRE statement
are those that are current at the time the statement is executed."

Since i am executing enquire before file is connected, value assigned
by enquire are for current time and since i have not opened the file
till now, ideally i should not be knowing the FORMATTED and
UNFORMATTED status at this point of time, so i should be returning
UNKNOWN.

Is my interpretation and reasoning correct..??

However, i think compiler can take is as an extension to open a file
and return appropriate status.

Thanks
Gaurav

On Feb 8, 10:26 am, nos...@see.signature (Richard Maine) wrote:

Richard Maine

unread,
Feb 8, 2007, 1:48:34 AM2/8/07
to
gaurav <gauravg...@gmail.com> wrote:

> Thanks for you reply. I ll try to be specific in what i want to know.
> I want to know what should be the status of parameters FORMATTED and
> UNFORMATTED when i am inquiring by file and file is not connected.
>
> I read the standard ((ISO/IEC:1539-1:1997)) and could gather that
> these two parameters should be UNKNOWN for this case.
>
> Reasons:
> 1) (table C.6.5)
> Value of FORMATTED is UNKNOWN if:
> a) Inquire by file is done and file is not connected.
> b) Inquire by Unit is done and file is not connected.

Hmm. Intriguing. I hadn't looked much at that table. I see why it
mislead you (at least I think it did). Good question.

However, I think I'm going to disagree with it. Note that it is in Annex
C, which is "informative". That term is standard-speak for a part of the
standard that is meant to elaborate, but in some sense is not a strict
part of the standard. When there is a discrepancy between the
"normative" and "informative" parts of the standard, the normative part
overrides (and that is usually good reason to suggest fixing the other
one).

For inquire by unit, I'd agree with the above. In that case, there isn't
a file to be inquired about. I don't think that unit numbers normally
have the property of being connectable to only formatted or only
unformatted files. I suppose I could be wrong on that, but it would
certainly be an esoteric case (except for the special case of the unit
numbers pre-connected to standard input/output, but then you won't
usually find thos eunit numbers unconnected).

But for inquire by file, I see no justification for the table entry.

The normative words are, from 9.6.1.11

"The scalar-default-char-variable in the FORMATTED= specifier is
assigned the value YES if FORMATTED is included in the set of allowed
forms for the file, NO is FORMATTED is not included in the set of
allowed forms for the file, and UNKNOWN if the processor is unable to
determine whether or not FORMATTED is included in the set of allowed
forms for the file."

These words say nothing about connected or not. They ar ethe words I was
thinking about for this particular case. Note also the important wording
about "allowed forms". This inquiry has little to do with whether the
file *IS* connected for formatted I/O. Instead, they have to do with
whether such a connection is allowed. One might assume that if the file
is connected for formatted, that it probably is allowed, though one
might be able to argue fine points about that. However, if the file is
connected for unformatted, that definitely does not mean that it isn't
allowed to connect it for formatted; some systems allow both. And it is
certainly possible on some systems to determine whether formatted or
unformatted is allowed even without actually trying the connection. Some
systems store information like that in the directory.

One can well imagine that implementations might just return unknown for
an unconnected file. Such an implementation would be valid. In fact, an
implementation that returned unknown for absolutely every formatted=
inquiry would be arguably valid, albeit unhelpful. But I see no
justification for claiming that an implementation is not allowed to
return a useful value for an unconnected file. That doesn't even count
as an extension; that's just an implementation choice.


> Since i am executing enquire before file is connected, value assigned
> by enquire are for current time and since i have not opened the file
> till now, ideally i should not be knowing the FORMATTED and
> UNFORMATTED status at this point of time, so i should be returning
> UNKNOWN.
>
> Is my interpretation and reasoning correct..??

Except for 2 things.

1. You assume that the processor can't know whether formatted is allowed
without connecting the file. This is not so. You might be
misinterpretting formatted= as asking whether the currect connection is
for formatted. That's not what it says. It asks whether formatted is
allowed. The distinction is important.

2. You (underatndably) believed the table in Annex C. I think that table
is wrong.

Dick. Are you listening? :-)

> However, i think compiler can take is as an extension to open a file
> and return appropriate status.

Um. No. A compiler can return appropriate status, but

1. That's not an extension - just an implementation choice.

2. The compiler can't just decide to open a file for reasons of its own.
That would be a violation of the standard - not an extension. Now
perhaps you are referring to "open" in a lower-level sense, in which
case I'd agree that would be one way for the processor to deduce things
about the file. But the file can't end up "opened" in Fortran terms.

0 new messages