Re: INQUIRE - FORM vs. (UN)FORMATTED

Tobias Burnus <burnus@xxxxxxxx> wrote:

I'm trying to understand the FORM, FORMATTED and UNFORMATTED specifiers
of INQUIRE.

Let's start with FORM:..
Ok, this is clear to me. Especially, it means given a UNIT (or a FILE
name) I can determine whether a file is connected and, if yes, whether
I need to access it as unformatted or formatted.

Well... I don't like your use of "need" there. While correct, I find it
potentially misleading. It tells you whether the file was opened (aka
connected) with formatted or unformatted. You "need" to use the way that
corresponds to the current open, but this says nothing about whether or
not you might also be able to use the other way on the same file with a
different open (at a different time).

First case: INQUIRE(NAME=existing_file,...), which is not
connected/opened. Well, "UNKNOWN" can of cause always returned, but are
there scenarios where one would return FORMATTED="YES" or "NO"?

Certainly. I suspect you must be thinking of implementation issues for
current operating systems, because the answer seems so obvious in
general. If the file can definitely be opened as a formatted file, it
returns yes. If it definitely cannot be, it returns no. But I just
restated what th e standard said without even changing the words much. I
can't think of a more obvious way to say it.

Now most current operating systems don't have a good way to tell. So I
suspect most compilers will probably return unknown. That's likely the
practical answer.

For a directory, one could e.g. return "NO". And in principle if a file
is readable, writtable and seekable there should be no problem opening
it - either as FORMATTED or as UNFORMATTED, whether one can read
something from the file is another question.

Not necessarily so. You are thinking of particular implementations. It
is quite possible that a system might refuse to open a file the "wrong"
way, and even that this could be at a level below that dealt with by the
Fortran run-time library. It is also quite plausible that the Fortran
run-time library might be "smart enough" to notice the problem and make
the OPEN fail. It could be regarded as a better approach than opening it
even though nothing will work. The Fortran library might get the data
from the OS. Most OSes today don't keep such data, but some have/do. Or
the Fortran run-times might even look at the first part of the file and
deduce what's up.

gfortran and g95 currently return for non-opened files: UNIT: "UNKNOWN"
NAME: Does not exists "UNKNOWN", directory "NO", File (regular,
block/character device, named pipe) "YES", else "UNKNOWN".
NAG f95, ifort and sunf95 return "UNKNOWN" which is always right.

Is the behaviour of gfortran/g95 correct?

Correct? Yes. The most user-friendly? That's more arguable. Worth doing
better? That's also arguable. Since current OSes don't tend to provide a
handly way to get this data reliably, I don't generally recommend that
users depend on it.

Second case: The file is opened.
What should be returned for (UN)FORMATTED? Simply FORMATTED = "YES" if
FORM="FORMATTED" and otherwise "NO"?

That one is definitely wrong. The YES part is likely correct, although
arguable pedanticly. If you suceeded in opening the file with formatted,
then presumably it is allowed. If it wasn't allowed, then one would have
hoped the OPEN would fail instead of suceeding and then claiming (vioa
inquire) that you weren't allowed to do that. Since error conditions are
compiler-defined, the pendant might argue differently, but that would
seem silly.

But just because the file is opened formatted says little about whether
it is capable of being opened unformatted. I suppose that if the system
was such that only one of the opens would work, you might make
thatdeduction, but that's not what I hear you saying. The standard says
"set of allowed" forms" - not "currently used form".

what is the purpose of the FORMATTED vs. UNFORMATTED?
Or should be returned whether it is in principle possible to open the
file as (UN)FORMATTED?

Yes, that's the idea. I don't know how to state igt any more explicitly
than the standard.

Then one would always return "YES" (I'm ignoring
issues like whether a file is seekable.)?

Not necessarily so. I see you making assumptions here based on common
current systems. There is nothing inherently so about that. It might
well not be possible in principle to open a file in the wrong mode. The
standard is broader than that (and was written at a time when there was
more diversity in operating systems).

In total, my problem is: What is meant by "in the set of allowed forms
for the file"?

I hope I explained, but I'm not sure. You need to back off from thinking
that what current common operating systems do is the only way. The words
seem simple to me. I think the problem arrises because the facility
isn't very useful with current operating systems and you are
overgeneralizing that. So you see a facility that seems useless and are
wondering why such a thing would ever be. THat's because it could be
(was) useful in other contexts.

PS: Besides an interpretation of the standard, I'm also interested what
would be useful to return - as "this is implementation dependent" has
also somehow to be implemented.

I'd probably just punt and return UNKNOWN for almost all cases, since
you basically can't tell without extra fuss - and users who depend on
you going to the trouble are going to have code portability problems
anyway. If you can detect some obvious cases, then it is ok to give the
data, but I wouldn't go out of yourt way. Just my opinion.

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

Relevant Pages

  • Re: IE6 browser doesnt open
    ... There are few recent operating systems where this can be done, ... MS MVP Windows - Internet Explorer ... NetZero, since IE browser usually opens with sign-on, however, an ... uninstall/reinstall didn't help. ...
    (microsoft.public.windows.inetexplorer.ie6.ieak)
  • Re: GEOM Gate committed!
    ... It is a simple network daemon that opens given device ... > or file and read from/write to it, ... > trivial to port it to other operating systems and exports disk devices ...
    (freebsd-current)
  • Re: Java file reading
    ... What exactly is java doing when it opens a filereader? ... I think some operating systems will force the connection shut after a certain amount of time but not sure. ...
    (comp.lang.java.programmer)
  • Re: dual booting XP and Linux
    ... Now, the last time I looked, Linux does *not* adhere to that standard. ... The target operating systems ... MS products predate the multiboot standard. ...
    (Fedora)
  • RE: Form load failed
    ... > My standard forms library has disappeared. ... > button, and the design form dialog opens, but no standard forms are shown. ... > Once the design form dialog box is open I can open other libraries like my ...
    (microsoft.public.outlook.program_forms)