-
Notifications
You must be signed in to change notification settings - Fork 674
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
Ubsan findings fixes #2498
Ubsan findings fixes #2498
Changes from all commits
9000d5f
4542088
bd5a581
1f30e29
2bc3b5a
58cbe10
4c09136
d6b9a80
98ed89a
40f327e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -88,7 +88,7 @@ std::string encode(const container_t& points, const int precision = 1e6) { | |
// handy lambda to turn an integer into an encoded string | ||
auto serialize = [&output](int number) { | ||
// move the bits left 1 position and flip all the bits if it was a negative number | ||
number = number < 0 ? ~(number << 1) : (number << 1); | ||
number = number < 0 ? ~(static_cast<unsigned int>(number) << 1) : (number << 1); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is again bit shifting a signed number and in this case we know its negative. im surprised this doesnt change lots of stuff.. one good test for this would be to run valhalla_export_edges on a larger tileset since it dumps out the whole tilesets shape. then we can look at the diffs in there to see what this does. maybe we were just lucky on the platforms that we run that the implementation dependent handling was equivalent to the above? we need to test this more rigorously There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even more lucky, because There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. well my suggestion was as i stated:
yep i am aware of the unit test (i wrote the original), but its not extensive. the reason i want to do a broader test is because this touches literally everything. every single route, mapmatch, how the data is stored. this is a fundamental change so we better be sure its ok. same with the other one above There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i wrote a small program just to check There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @kevinkreiser I did the testing we discussed
|
||
// write 5 bit chunks of the number | ||
while (number >= 0x20) { | ||
int nextValue = (0x20 | (number & 0x1f)) + 63; | ||
|
@@ -134,7 +134,7 @@ template <class container_t> std::string encode7(const container_t& points) { | |
auto serialize = [&output](int number) { | ||
// get the sign bit down on the least significant end to | ||
// make the most significant bits mostly zeros | ||
number = number < 0 ? ~(number << 1) : number << 1; | ||
number = number < 0 ? ~(static_cast<unsigned int>(number) << 1) : number << 1; | ||
// we take 7 bits of this at a time | ||
while (number > 0x7f) { | ||
// marking the most significant bit means there are more pieces to come | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah so bitshifting signed numbers is implementation dependent so im not sure what was happening here. i'm not sure if we have any negative numbers in the input but if we do this change will definitely have an impact on what we do with the data. i'll follow up with you offline with some sample data to see if we need to worry about it