Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!news
From: CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel)
Newsgroups: comp.lang.pascal
Subject: (R)Blockread/write problem
Message-ID: <24384@adm.BRL.MIL>
Date: 4 Sep 90 17:09:09 GMT
Sender: news@adm.BRL.MIL
Lines: 72


In <26E201B9.5523@ics.uci.edu>, Alastair Milne <milne@ics.uci.edu>
  writes

>In <24352@adm.BRL.MIL> CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel)
> writes:
>
>>Because the original code provided a variable for the optional "result"
>>parameter, BlockRead would not cause an I/O error (or a non-zero
>>IOResult) when reading the last partial block. It _would_, indeed, read
>>that partial block into the buffer. Unfortunately, there would be no
>>explicit indication that a partial block had been read.
>
>  I'll double-check the documentation, but I don't believe that the
>  result parameter and IOResult are mutually exclusive.  If your read
>  request wants more than is left in the file, you will still get
>  a non-0 IOResult, whatever the NumberRead parameter reports.
>
>  I agree that it would read the partial block (I also think the whole block
>  should be zeroed first so that the unread part does not remain garbage)
>  but that would set the IOResult so what *would* get suppressed is the
>  following BlockWrite.

I've followed this up here just for the sake of others, in case your
double-checking doesn't result in a message to the list.

The 5.X Ref Guide documentation on BlockRead says:

  BlockRead(var f: file; var buf; count: word [; var result: word])
...
  BlockRead reads count or less records from the file f into memory,
  starting at the first byte occupied by buf. The actual number of
  complete records read (less than or equal to count) is returned in the
  optional parameter result. If result is not specified, an I/O error
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  will occur if the number read is not equal to count.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
  result is an optional parameter. Here is how it works: If the entire
  block was transferred, result will be equal to count on return.
  Otherwise, if result is less than count, the end of the file was
  reached before the transfer was completed. In that case, if the file's
                                                           ^^^^^^^^^^^^^
  record size is greater than one, result returns the number of complete
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  records read; that is, a possible last partial record is not included
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  in result.
  ^^^^^^^^^^
[end of quotation] (All ^^^^^^^ emphasis added during typing. :))

If what I've said previously still doesn't ring true, I'll be glad to
email you directly. It would be better for you to experiment with it a
little, though.

FWIW, while 0ing buffers can often be helpful, in this case even those
0s are probably garbage if you haven't tracked where the final read
ends. In any case where a final read can produce a valid partial
record, I know of no general way to avoid garbage other than to do your
own tracking of the end of the file. The best approach is probably to
declare a "recsize" of 1, and to read blocks of convenient, larger sizes
(multiples of your true record length, if there is one). Then "result"
always tells you how many bytes you got from the read, and anything
beyond that number is garbage.

+-------------------------------------------------------------------------+
| Karl Brendel                                Centers for Disease Control |
| phone 404/639-2709                          Epidemiology Program Office |
| fts       236-2709                          Atlanta, GA                 |
|                                                                         |
|                        Home of Epi Info 5.0                             |
+-------------------------------------------------------------------------+