
I'm not sure if this counts as a bug or a feature...
If hGetPS h len encounters an EOF before len, it returns a PackedString containing the remainder of the file. However, if h is already at the end of the file, an exception is raised rather than returning an empty string. To me this is rather counter-intuitive.
It matches the behaviour of System.IO.hGetLine. Data.PackedString.hGetPS behaves in the way you're suggesting: it just returns short reads instead of flagging EOF. Unfortuantely this is inconsistent with hGetLine, so I'm not sure if the behaviour should stay that way. Cheers, Simon

On Mon, Apr 28, 2003 at 11:32:53AM +0100, Simon Marlow wrote:
I'm not sure if this counts as a bug or a feature...
If hGetPS h len encounters an EOF before len, it returns a PackedString containing the remainder of the file. However, if h is already at the end of the file, an exception is raised rather than returning an empty string. To me this is rather counter-intuitive.
It matches the behaviour of System.IO.hGetLine.
Data.PackedString.hGetPS behaves in the way you're suggesting: it just returns short reads instead of flagging EOF. Unfortuantely this is inconsistent with hGetLine, so I'm not sure if the behaviour should stay that way.
I don't see that hGetPS should be consistent with hGetLine. If hGetLine returns and empty string, you assume the file has two newlines in a row, while if hGetPS returns an empty string, since you asked for a given number of chars, you know that you've reached the end of the file. -- David Roundy http://www.abridgegame.org
participants (2)
-
David Roundy
-
Simon Marlow