[fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes
michalis.kambi at gmail.com
Sun Jun 16 20:00:43 CEST 2013
Michael Van Canneyt wrote:
> The above implementation should not be changed, it is Delphi compatible:
> TStream.ReadBuffer works on the assumption that Read will always return
> the amount of bytes requested if they are available.
> So, if you want to make changes, there is no reason why TStream.Read
> should not benefit from 'trying harder', it could try harder to actually
> get the requested number of bytes from the underlying low-level
> implementation. Some TStream descendents already work that way
> (compression, hash, encoding), others don't.
> This in turn means that affected TStream descendents such as TFileStream
> or THandleStream should try harder to read the requested number of
> bytes, taking into account the
> specifics of the underlying file/socket/whatever protocol.
In effect, you want to change all the streams Read method
implementation, such that it returns less than requested Count *only*
when the stream actually ended...
What about socket streams that potentially download the data? Or
THandleStream streams that *may* read/write data from/to a pipe, like
stdin/stdout, and may have to wait for another process? Should their
TStream.Read really hang, waiting for Count data?
1. See Ewald objections. Like Ewald, I also think it is useful to have a
TStream.Read that only returns the amount of data that is immediately
available (and hangs only when no data is available yet).
2. This would be large work, IMHO... I propose to fix a single
TStream.ReadBufffer implementation (well, and TStream.WriteBuffer). You
propose to fix Read method in all stream descendants, inside and outside
More information about the fpc-pascal