[fpc-pascal] TStream.ReadBuffer doesn't try hard enough to read the requested bytes

[Michalis Kamburelis]

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 
FPC sources.

Michalis