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

Negative varints are not handled correctly. #141

Closed
py-mine-bot opened this issue Feb 15, 2022 · 0 comments
Closed

Negative varints are not handled correctly. #141

py-mine-bot opened this issue Feb 15, 2022 · 0 comments
Labels
Github Import This was auto-imported from upstream repository type: bug Something isn't working

Comments

@py-mine-bot
Copy link
Collaborator

CoolCat467 Authored by CoolCat467
Jun 16, 2021
Closed Jun 21, 2021


Negative varints are not handled correctly because in Python, numbers are represented with infinite bits instead of 32 or 64, meaning right shift including sign bits does not exist, meaning this implementation only does regular right shift. This causes varints (at the moment) to be able to handle positive integers from 0 to 2 ** 35 - 1 instead of the true range minecraft uses of integers from -2 ** 31 to 2 ** 31 - 1. I predict no one has noticed this before because in this script's usual function, the varint implementation is only used for reading text length, and since text length is never negative it has never been noticed.

@py-mine-bot
Copy link
Collaborator Author

CoolCat467 Authored by CoolCat467
Jun 16, 2021


So, interesting story behind me finding this. I'm planning to use the connection module in one of my upcoming projects, and was curious about this varint thing I kept seeing in parts handling buffers and text. I saw by it's read write functions it's limited in size to 5 bytes, so I was wondering what the size constraints were and started doing research. I found a webpage about it, it told me the limits, and I decided to test it, and I found negative numbers broke it and that positive numbers could go far higher than 2 ** 31 - 1, so I started looking into why. All the code is nearly exactly the same as a C demonstration of it, except that pesky "sign bit is shifted with the rest of the number rather than being left alone" operator ">>>=" being ">>=" since it doesn't exist in python.

@py-mine-bot py-mine-bot added type: bug Something isn't working Github Import This was auto-imported from upstream repository labels Feb 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Github Import This was auto-imported from upstream repository type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant