Peter Norton wrote:
I cannot reproduce it, but I suppose it's just a misunderstanding of the `BlockRead' semantics. If the 4th parameter is given, it doesn't have to read the whole buffer because the 4th parameter tells how many were read.
I always thought that forth parameter in 'BlockRead' contains information how much units was read. How much to read is controlled by the third parameter.
Yes -- except that the 3rd parameter is the maximum to read. Reading less (but complete records, in case record size is > 1 bytes) is acceptable. Only reading nothing means end of file.
Newertheless your code works fine - it just make one more loop on the eof.
Depends on the code. You can either check `EOF' or test if the result (4th parameter) is 0. Or you can do both to be sure -- it may be redundant, but it shouldn't really hurt.
I'm still interest what prevent to fill the full buffer (512 bytes) on this magic poiner 16384.
I'm not sure since I can't reproduce it. Maybe it's related to either GPC's internal buffers or your OS's semantics (I think some OSs read only some maximum size in one call, again there's nothing wrong with it). BTW, which OS and which GPC version? Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707