Mail Archives: djgpp/2004/12/18/16:46:03
Apparently we are seeing that using fread()
and reading a size that exceeds the end_of_file,
causes ZERO elements to be returned; this
does not seem to be what most people are expecting:
Example 1:
aFile.bin, Size = 256 bytes
(an arbitrary file, containing random characters,
of a specific size, purely for example)
unsigned char Buffer[256];
n = fread(Buffer, sizeof(char), 128, In_File);
n should equal 128 (and will work for any file 128 bytes or larger!)
File pointer (ftell) will now be at the 129th position.
a = fread(Buffer, sizeof(char), 64, In_File);
//ftell() = 256 - 128 - 64 = 64 from End_of_File
b = fread(Buffer, sizeof(char), 128, In_File);
A tiny bit of a problem:
LengthOfFile can not accomodate another 128 byte
read, however, we would still like to optain the LAST
block of available bytes !!
b will equal 0 apparently,
and the Buffer content won't have what was expected
to be the last block read??? (the last 64 bytes up to
the actual end_of_file) ???
This is the question:
What is the DJGPP philosophy on how fread is expected
to function? And how can it be enforced for the TYPE
of data required:
Consider the "simplicity" of my example; merely reading a
unsigned char block of data..., compare that to something
a little *more* specific in nature like a Int's or Long's,
where in order to obtain a TOTAL element 2, or 4 bytes
*MUST* be read, or the call to fread is pointless;
if I can't obtain the precise type of data required in tact!
*BUT* in the case of a mere block of 'unsigned char'
it eliminates success completely, without a lot of work
to tract remaining bytes so a call to fread 'KNOWS' what
to expect in real terms of block-size....
Lets discuss this a little. Thansk!
email:RadSurfer AT yahoo DOT com
- Raw text -