Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-generic streams (make MsgStream a proper Stream) #71

Merged
merged 3 commits into from
Feb 24, 2023

Conversation

snej
Copy link
Contributor

@snej snej commented Dec 12, 2022

I found a way to make MsgStream a proper subclass of Stream and initialize it correctly. It’s a bit of a kludge but it works; really it’s just a workaround of a design flaw in the streams module.

That means the implementation of the stream API can be removed, since it’s all inherited now.

It also means that all the functions that operate on streams can be regular non-generic procs that take a Stream parameter, instead of needing to make them generic over a ByteStream type.

In doing this I found a place where MsgStream had different semantics from a regular Stream: the readStr function here would raise an IOError if it couldn’t read the entire string; the standard one doesn’t. I think raising an error is better behavior, but it’s nonstandard. I resolved this by defining a new function readExactString(Stream) that has the MsgStream behavior, and changing all calls to readString to readExactString.

Note: this means there is a bug in the current master branch: If StringStream or FileStream is used to unpack, instead of MsgStream, truncated input won’t necessarily be detected. The unpack call might incorrectly return output containing a truncated string, instead of raising an exception as it should.

The original implementation of MsgStream (before it was a subclass of
Stream) had `readStr` procs that raised an IOError if the entire
string couldn't be read. This does not match the behavior of the
standard Stream module, but the code here depends on it, and the
lack of this check broke a unit test.

(Note: This meant MsgPack had different behavior when using a regular
stream than when using a MsgStream. In the former case, some truncated
messages wouldn't be detected during unpacking, and bad data would be
returned.)

I created a Stream.readExactStr function that has the behavior the
code here expects, and changed all the calls to `readStr` to
`readExactStr`.
Now that MsgStream inherits from Stream, all procs that take a
stream can just be regular procs with a `Stream` parameter, instead
of generics.
@jangko jangko merged commit 6c7cf20 into jangko:master Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants