Direct answer
There is no portable way to detect record-delimiter misalignment from inside a standard Fortran program. The language deliberately leaves unformatted sequential record markers processor-dependent, so a conforming READ cannot ask whether the framing is aligned. A nonzero IOSTAT tells you only that the read failed; it cannot distinguish a delimiter mismatch from truncation, end-of-file, or data corruption. Verifying a recovered file without the original writer requires external metadata—principally a cryptographic hash and the writer’s layout assumptions.
Likely explanation vs. confirmed facts
The likely explanation for a cross-compiler failure is a record-marker mismatch: 4-byte versus 8-byte length words, opposite byte order, word-boundary padding, or subrecord markers for very large records. The confirmed fact is that the Fortran standard specifies none of these details, so each compiler is free to choose its own physical layout.
Why IOSTAT is not a classifier
The standard guarantees only that IOSTAT is zero on success and nonzero on failure. IOSTAT_END and IOSTAT_EOR are named constants, but every other value is an implementation-defined runtime error number. Capture IOMSG alongside IOSTAT for context, but do not hard-code specific numbers into recovery logic; they vary by compiler version and platform.
Steps for this case
- Hex-dump the first 64 bytes and interpret the leading four bytes as a signed 32-bit integer in both byte orders. Keep whichever value is positive and smaller than the file size, then check whether the trailing marker at that offset equals the leading marker.
- Open the file with
ACCESS='STREAM', FORM='UNFORMATTED' and walk the marker chain yourself. Report the first offset where a trailing marker differs from its leading marker. This bypasses compiler-specific sequential logic entirely.
- Compare the recovered file’s byte size and SHA-256 against values captured at write time. If no checksum exists, record one now and treat the file as unverified.
- Re-read the same file under each candidate compiler option set, printing
IOSTAT and IOMSG side by side. The set that produces clean reads with expected record lengths is the likely writer configuration.
Metadata required without the original writer
| Metadata | Why it matters |
|---|
| Byte size and SHA-256 | Detects truncation or silent text-mode corruption |
| Writer compiler and version | Infers default marker width and padding rules |
| Record marker size and conversion flags | Reproduces framing assumptions |
| Platform endianness | Separates marker byte order from data element byte order |
| Record count and per-record lengths | Validates the recovered chain against the expected schema |
If framing is intact but values look wrong
Then the problem is probably data element byte order rather than record delimiters. These are independent concerns; options that convert data elements do not necessarily correct record markers. Test each conversion empirically instead of assuming.
Assumptions and uncertainty
Assume a modern gfortran or Intel Fortran compiler. Exact default marker sizes, padding rules, and IOSTAT codes are version- and platform-dependent. A file that reads cleanly under one option set is not necessarily byte-identical to the original; framing success and content correctness are separate checks. The single most useful missing diagnostic is a hex dump of the first 64 bytes, because it determines whether the fix is marker reinterpretation or byte-order conversion.
fortran