Fortran - reading back a partially-written record on direct access

Author

reading back a partially-written record on direct access

Thomas König

2007-03-31, 4:06 am

Is the following program standard-conforming?

PROGRAM test
IMPLICIT NONE
CHARACTER*8 as_written, as_read
INTEGER irec
INTEGER i
as_written = "12345678"
inquire (iolength=irec) as_written, i
OPEN (76, FILE="test.txt", ACCESS="DIRECT", STATUS="NEW",
& RECL=irec)
WRITE(76, REC=1) as_written
READ(76, REC=1) as_read, i
PRINT *, "as_written = ", as_written, " as_read = ", as_read
CLOSE(76)
END PROGRAM test

I don't think it is, because it reads something that wasn't written
(the variable i). On the other hand, i isn't used, so it may be OK.

glen herrmannsfeldt

2007-03-31, 4:06 am

Thomas König wrote:

> Is the following program standard-conforming?
>
> PROGRAM test
> IMPLICIT NONE
> CHARACTER*8 as_written, as_read
> INTEGER irec
> INTEGER i
> as_written = "12345678"
> inquire (iolength=irec) as_written, i
> OPEN (76, FILE="test.txt", ACCESS="DIRECT", STATUS="NEW",
> & RECL=irec)
> WRITE(76, REC=1) as_written
> READ(76, REC=1) as_read, i
> PRINT *, "as_written = ", as_written, " as_read = ", as_read
> CLOSE(76)
> END PROGRAM test
>
> I don't think it is, because it reads something that wasn't written
> (the variable i). On the other hand, i isn't used, so it may be OK.
>

9.5.3.4.1 "On output to a file connected for unformatted direct access,
the output list shall not specify more values than can fit
into the record. If the file is connected for direct access
and the values specified by the output list do not fill the
record, the remainder of the record is undefined."

The value of I is at least undefined.

-- glen

Richard Maine

2007-03-31, 7:03 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Thomas König wrote:
>
>
> 9.5.3.4.1 "On output to a file connected for unformatted direct access,
> the output list shall not specify more values than can fit
> into the record. If the file is connected for direct access
> and the values specified by the output list do not fill the
> record, the remainder of the record is undefined."
>
> The value of I is at least undefined.

I think Glenn has the core of it here. You also need the bit somewhere
else that says the records in a direct access file are all the same
length; otherwise one might imagine a short record being written, in
which case the read would be invalid. I think that the read is valid,
but the variable "i" becomes undefined. But I'll admit there might be
room to question that. I'd have to research a bit further to be
completely sure. There might be a requirement somewhere that the record
contain an integer to correspond with "i". If so, the rest of the record
being undefined would violate that. I'm too lazy to look further right
now, but that's at least a hint of the kind of thing I'd look for.

Do note one picky and slightly quirky side point. Although I think the
read is ok, your inquire is not. That's because inquire is defined to
use an output list. Variables in an output list must be defined. Your
"i" variable isn't. I think I recall actually getting bit by a more
complicated case of this once. I tend to think of the inquire statement
as like an inquiry intrinsic in that it only needs to know properties
(in particular, sizes) and not values. Thus you might think that the
values don't need to be defined. But the way it is specified in the
standard, they do need to be defined for the inquire statement.

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

glen herrmannsfeldt

2007-03-31, 7:04 pm

Richard Maine wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> I think Glenn has the core of it here. You also need the bit somewhere
> else that says the records in a direct access file are all the same
> length; otherwise one might imagine a short record being written, in
> which case the read would be invalid. I think that the read is valid,
> but the variable "i" becomes undefined. But I'll admit there might be
> room to question that. I'd have to research a bit further to be
> completely sure. There might be a requirement somewhere that the record
> contain an integer to correspond with "i". If so, the rest of the record
> being undefined would violate that. I'm too lazy to look further right
> now, but that's at least a hint of the kind of thing I'd look for.

Yes, I should have mentioned the length.

Regarding undefined values, comp.lang.c discussions sometimes
indicate that there could be invalid values to some variables,
such that even assigning them to a variable could be illegal.
That could be -0 on machines with an integer -0, it could
be a signaling NaN on machines that support it. I don't know
what IEEE says about signaling NaN enough to know. There
are also stories about machines where one can load values
with illegal parity. Probably that means you shouldn't
reference I after the read, but it might also be that the
read itself could cause problems. Not likely on current
machines, though, except possibly the signaling NaN.

> Do note one picky and slightly quirky side point. Although I think the
> read is ok, your inquire is not. That's because inquire is defined to
> use an output list. Variables in an output list must be defined. Your
> "i" variable isn't. I think I recall actually getting bit by a more
> complicated case of this once. I tend to think of the inquire statement
> as like an inquiry intrinsic in that it only needs to know properties
> (in particular, sizes) and not values. Thus you might think that the
> values don't need to be defined. But the way it is specified in the
> standard, they do need to be defined for the inquire statement.

That does seem surprising. I presume it doesn't depend on the
actual value, though.

Also relating to unformatted direct access files in 9.5.3.4.1:

"On input, if the file storage units transferred do not contain
a value with the same type and type parameters as the input list
entity, then the resulting value of the entity is
processor-dependent except in the following cases:

(1) A complex list entity may correspond to two real values
of the same kind stored in the file, or vice-versa.

(2) A default character list entity of length n may correspond
to n default characters stored in the file, regardless of the
length parameters of the entities that were written to these
storage units of the file. If the file is connected for
stream input, the characters may have been written by
formatted stream output.

This one says processor dependent, not undefined. Consider:

PROGRAM test
IMPLICIT NONE
CHARACTER*8 as_written, as_read
INTEGER irec
INTEGER i,j=1
as_written = "12345678"
inquire (iolength=irec) as_written, j
OPEN (76, FILE="test.txt", ACCESS="DIRECT", STATUS="NEW",
& RECL=irec)
WRITE(76, REC=1) as_written, j
READ(76, REC=1) i, as_read
PRINT *, "as_written = ", as_written, " as_read = ", as_read
CLOSE(76)
END PROGRAM test

To me, processor dependent means it is legal, but the values
of as_read and i are not defined by the standard.

-- glen

Richard Maine

2007-03-31, 7:04 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Richard Maine wrote:
[color=darkred]
> Regarding undefined values, comp.lang.c discussions sometimes
> indicate that there could be invalid values to some variables,
> such that even assigning them to a variable could be illegal.

Yes. I was thinking along those lines - bit patterns that might not be
allowed in some types. Apparently the standard doesn't allow for such a
case. Note that TRANSFER has simillar issues.

> Also relating to unformatted direct access files in 9.5.3.4.1:
>
> "On input, if the file storage units transferred do not contain
> a value with the same type and type parameters as the input list
> entity, then the resulting value of the entity is
> processor-dependent except in the following cases:
[cases that aren't this one]

Thanks for doing the research. That's exactly the critical bit. So it
says that the read is valid, but the result is processor dependent.

> This one says processor dependent, not undefined. Consider:

Yes. That minorly surprises me. I might have thought undefined. But in
either case, the read is valid; the only distinction is in whether or
not it is subsequently valid to reference the variable. The original
code in question did not reference the variable, so I conclude it was
standard-conforming (except for the inquite thing).

I suppose that by saying the result is processor-dependent instead of
undefined, the standard is more-or-less condoning unformatted I/O as a
way of doing the equivalent of a TRANSFER, which also gives a
processor-dependent result. The I/O wording doesn't say the same things
as TRANSFER about the bits being identical, it's true.

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

Sponsored Links