Can anyone tell me what the standard says about using fseek (on a binary
I'm curious why you would, and what you would expect to find,
seeking past end-of-file. Perhaps I misunderstand.
Under UNIX it is possible to seek past end-of-file, write something
(which moves the end-of-file to the end of what you wrote), and
later seek again and read it. Reading unwritten data reads back
binary 0 bytes. On some versions of UNIX disk "blocks" that were
wholly unwritten were also not allocated, leaving the possibility
of the gigabyte-sized file that fits on a floppy-sized filesystem.
Still curious, how would you know where end-of-file is and that you
are seeking past it?
Many uses for this odd kind of indexed file don't CARE where the
end-of-file is. You compute a hash code for the data record key,
multiply it by the data block size, and that's where you put the
data. If you want to read such a record, you hash the key, multiply
it by the data block size, and try to read it. If you get all bytes
zero or end-of-file, there is no record written there. Hash collisions
are dealt with by putting multiple entries in a "data block", or
by using more bits in the hash to locate a different block.
The above is a crude description of how a UNIX "dbm" file works.
It typically occupies about 1/4 of the disk space than what you'd
expect based on its size.
beginning of the file, the end of the file and relative offsets
within the file. The actual address is of type long. Assuming a
properly opened file (FILE *fp) of some size, ..
long bof = 0; /* no calc needed. files begin at 0 */
long eof; /* just define it for now */
if (fseek(fp, 0, SEEK_END) != 0) puts("fseek failed, die"), exit(9);
eof = ftell(fp);
Now eof is actually the file length. It 'points' one byte after the
last byte in the file, actually to where the next byte might be
written.
But 'past end-of-file' has no meaning to me. end-of-file + 3?
fseek(fp, 32767, SEEK_END);
Gordon L. Burditt