🚀 go-pugleaf

I've run into a problem with the Fread() gemdos macro.  Using Megamax I
wrote a piece of code to buffer line-by-line input.  The code reads files
by 8K blocks at a time.  There's no problem as long as the call to Fread()
requests a block smaller than the rest of the file being read.  For
example, if I read 1000 bytes from a 3000 byte file Fread() returns 1000
and there are exactly 1000 characters stored in the buffer specified.  If
there are only 300 bytes in the file and I request 1000 Fread() will return
301 and the 301st byte is a ^Z.  Since ^Z is the EOF character in gemdos It
appears that Fread() is actually reading one character past/into the end of
file and sticking that character at the end of the input buffer.

Please don't reply with work around solutions to this.  I've already worked
around it.  I just wanted to see if anybody else has run into this problem
and if they've found a real solution for it.  In most cases this isn't much
of a problem but it's something to watch out for when comparing files.  It
looks like the files are actually starting to diverge from each other when
in fact one has ended.  These are two entirely different things and this
bug makes the later trickier to detect.

I'm also not sure if this is only related to Megamax or is a bug in the
gemdos call itself.  Megamax seems to think it's gemdos.  I'm not sure
since Megamax has to provide the gemdos() library call that's used to
invoke the lower level routines and that could be where the problem is
occurring.  Has anyone seen this problem with any of the other C
development systems?

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)