You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The majority of Zinc-provided Stream classes, e.g. ZnBuffered{Read|Write}Stream, ZnEncodedStream, use an implementation of #skip: that silently does nothing when given a negative argument. Some of them have good reasons for not supporting skipping backwards, but effectively ignoring the call can introduce subtle, difficult-to-debug issues. I would at minimum expect an error if the stream is asked to do something it cannot do, and in some cases there would be little or no difficulty implementing backwards #skip:, at least within a limited range.
To Reproduce
Steps to reproduce the behavior:
Open a file for reading, e.g. 'foo.txt' asFileReference readStream.
Attempt to skip backwards in the stream, e.g. after an upTo: in order to not actually consume the delimiter.
Wonder why there are missing characters in your output because the stream didn't actually skip back.
Expected behavior
Either correctly skipping backwards (this would be preferable for file streams in particular), or an Error if the stream cannot practically support skipping or you ask for a skip that goes back too far (reasonable for socket streams). A correct skip-backwards for variable-width encoded streams (UTF-8), in particular, is a further complication. I'd be happy in that case with a correct skip-backwards-by-one only—an implementation of PositionableStream>>back rather than a generalized negative #skip:.
Version information:
OS: Any
Version: Any
Pharo Version: 8, but unless this has changed dramatically in 9 I imagine it applies to all versions.
Expected development cost
Adding a simple count < 0 ifTrue: [self error: 'Cannot skip backwards'] or the like to the top of the relevant implementations would be trivial, and I'd be happy to do so if this is the preferred resolution. Correctly implementing skip-backwards for those streams that could practically support it isn't much more work, but I would want anything I did reviewed by someone familiar with their internals to make sure it covers all edge cases.
The text was updated successfully, but these errors were encountered:
Thanks, good to have the gotcha taken care of. I did make a follow-up issue for implementing at least #skip: -1/#back, as this is a very useful capability in conjunction with methods like #upTo:.
Bug description
The majority of Zinc-provided Stream classes, e.g.
ZnBuffered{Read|Write}Stream
,ZnEncodedStream
, use an implementation of#skip:
that silently does nothing when given a negative argument. Some of them have good reasons for not supporting skipping backwards, but effectively ignoring the call can introduce subtle, difficult-to-debug issues. I would at minimum expect an error if the stream is asked to do something it cannot do, and in some cases there would be little or no difficulty implementing backwards #skip:, at least within a limited range.To Reproduce
Steps to reproduce the behavior:
'foo.txt' asFileReference readStream
.upTo:
in order to not actually consume the delimiter.Expected behavior
Either correctly skipping backwards (this would be preferable for file streams in particular), or an
Error
if the stream cannot practically support skipping or you ask for a skip that goes back too far (reasonable for socket streams). A correct skip-backwards for variable-width encoded streams (UTF-8), in particular, is a further complication. I'd be happy in that case with a correct skip-backwards-by-one only—an implementation ofPositionableStream>>back
rather than a generalized negative#skip:
.Version information:
Expected development cost
Adding a simple
count < 0 ifTrue: [self error: 'Cannot skip backwards']
or the like to the top of the relevant implementations would be trivial, and I'd be happy to do so if this is the preferred resolution. Correctly implementing skip-backwards for those streams that could practically support it isn't much more work, but I would want anything I did reviewed by someone familiar with their internals to make sure it covers all edge cases.The text was updated successfully, but these errors were encountered: