Re: reading back a partially-written record on direct access

Richard Maine wrote:

glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> wrote:
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.

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

.

Relevant Pages