Michael Van Canneyt wrote:
If an implementation of Read does not return the requested data when in fact it is available, then the implementation of Read is broken.
I guess it depends how do you interpret TStream.Read documentation... http://www.freepascal.org/docs-html/rtl/classes/tstream.read.html does not explicitly say that TStream.Read returns less than requested Count *only when the stream ends*. And I saw a lot of code working under the assumption that only when TStream.Read returned zero -> then the stream ended.
If you want to put stricter requirements on TStream.Read, I suggest to update the docs to explicitly say this.
Your proposal is a quick and dirty hack that does not address the real problem.
Whether it's a hack or not really depends on your definition of "correct TStream.Read implementation".
My proposal is also a single solution that will make ReadBuffer correct for all the eternity.
Your proposal means that we have to fix THandleStream (Read and Write), which is definitely broken according to your requirements. Then we check TGZFileStream (I'm not sure whether it's already correct; it is definitely incorrect if gzRead in PasZLib is equivalent to gzRead inside C Zlib). And then every time I use another TStream implementation I'll have to check whether it's Read method is trying hard enough. TStream.Read that doesn't try hard enough is a very sneaky bug, since it will often work by accident (if reading small enough data).
Michalis _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
