Skip to content

Conversation

@shabbyrobe
Copy link
Contributor

@shabbyrobe shabbyrobe commented Jan 29, 2018

Been running this in production for a while now. This fixes #134 to meet the behaviour of other clients, which encode non-negative integers as unsigned regardless of whether the originating type is signed.

It raises an error on underflow or overflow and is tested pretty thoroughly (though I'm always happy to add more).


This change is Reviewable

@dchenk
Copy link
Contributor

dchenk commented Jan 29, 2018

I like this, but I don't see why ReadUint64 needs to be extended to signed integers. It's unlikely that feature will ever come in useful to anyone.

@shabbyrobe
Copy link
Contributor Author

If it doesn't hurt, and it works, why not? The spec is totally unclear about this one way or the other. What's to stop some client from implementing it the other way, and who would we be to say they were wrong?

Copy link
Member

@philhofer philhofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to merge this once you get the build passing.

failBits int
errCheck func(err error, failBits int) bool
}{
{math.MaxInt64, i32, 32, overflowErr},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these need explicit casts in order to make the 386 build pass

@shabbyrobe
Copy link
Contributor Author

Oops, yep, sorry about that. I've fixed it up and it's passing on my machine with GOARCH=386, hopefully Travis doesn't spit chips!

@philhofer philhofer merged commit 03a7918 into tinylib:master Jan 30, 2018
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.

question: on uint vs. int decoding.

3 participants