X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Radical NetSurfer <RadSurfer AT yahoo DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: v2.953 Additional Observations
Date: Sat, 18 Dec 2004 12:17:45 -0500
Message-ID: <boo8s01asckvrn9mb24hdl9fkjjq3bqq1g@4ax.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: Velocity.Net
Cache-Post-Path: web.velocity.net!unknown AT 66-211-204-213 DOT velocity DOT net
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
Lines: 57
X-Complaints-To: abuse AT newshosting DOT com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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