Message from discussion record length in an unformatted (binary) file
Received: by 10.204.6.19 with SMTP id 19mr17549bkx.8.1349942822080;
Thu, 11 Oct 2012 01:07:02 -0700 (PDT)
From: glen herrmannsfeldt <g...@ugcs.caltech.edu>
Subject: Re: record length in an unformatted (binary) file
Date: Sun, 7 Oct 2012 22:09:15 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: <email@example.com> <ad09cjF9qivU1@mid.individual.net> <firstname.lastname@example.org> <1krbvw4.ot6uri1f1xykoNemail@example.com> <firstname.lastname@example.org> <1krfwji.vqax2417ngrl8Nemail@example.com> <firstname.lastname@example.org>
User-Agent: tin/1.9.6-20100522 ("Lochruan") (UNIX) (Linux/2.6.32-5-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.8.2
marcio.pmz <mtnobrega....@gmail.com> wrote:
>> Also, it looks to me like you have an off-by-one error unless the code
>> compensates for it elsewhere. After exiting the loop, the value of ireg
>> is the one that failed rather than the last one that worked.
> Surely there is this off-by-one error, which I haven't noticed and didn't know
> had a name, but I won't forget. I corrected it, thank you!
> Still concern this issue of record length I am curious: what
> about the unit length of it? I know that it is 32 bits (word)
> by default, and it is supposed to work fine for integer kind 4
> and real kind 4, in Intel Compiler, but if I wished to read a
> real kind 8 (64 bits)? Would I have to use double recl,
> multiply by 2? I mean, if I need to read one value from a
> file it would be like this?
As well as I understand it, the read should follow as closely
as possible to the actual case.
Though the standard requires (though implementations might not
comply) the default INTEGER, REAL, and LOGICAL to have the same
size, relying on it might cause problems. As far as I know, it
isn't usual to do alignment padding for UNFORMATTED I/O, but
you probably shouldn't count on it not being done.
Interestingly there is right now in anohter newsgroup discussion
on the RECFM=VBS data format used by OS/360 and successors,
including the current z/OS. It seems that the record length is
not allowed to be zero. Normally, that shouldn't cause any
problem, but if you tried to test for it you wouldn't be able
to distinguish 0 bytes from 1 byte. (An array of LOGICAL*1.)
I don't know that the standard prohibits any kind of padding, maybe
rounding to the next multiply of 8 or 16 bytes, or even 512 byte
block. (That, in addition to the previously mentioned lack of
requirement to report the error at all.)
I do remember using BASIC systems years ago that padded direct access
I/O to whole block boundaries. It was usual to carefully construct
records of 256 or 512 bytes.