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

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

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
.

Relevant Pages

  • Re: Kind of NOT integer constant
    ... When the standard says that something is implementation ... generally are not required to be consistent in performing ... processor-dependent things. ... in this case the two implementations chose ...
    (comp.lang.fortran)
  • Re: Fortran
    ... > The F66 standard says something like the value is undefined. ... If something is nonstandard, ... variables is nonstandard and indeed won't compile at all with some ... If something gives a processor-dependent result, ...
    (comp.lang.fortran)
  • Re: Reinitialising random number generator
    ... detail in the writing of the standard. ... claimed that he had intended to specify whether the processor-dependent ... write down intended specs, as well as the irony of him in particular ... In the case of something like a standard, ...
    (comp.lang.fortran)
  • Re: Gfortran 2006 Year End Status Report
    ... if "the result is processor-dependent" actually allows throwing an error ... that phrasing in the standard says that the ... particular result value is what is processor dependent. ...
    (comp.lang.fortran)