This is an archive of the discontinued LLVM Phabricator instance.

[libc][Obvious] Fix a mismatch signature of HighPrecisionDecimal::should_round_up.
ClosedPublic

Authored by lntue on Feb 2 2022, 7:21 AM.

Details

Summary

Its input should be int32_t instead of uint32_t.

Diff Detail

Event Timeline

lntue created this revision.Feb 2 2022, 7:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 2 2022, 7:21 AM
lntue requested review of this revision.Feb 2 2022, 7:21 AM
sivachandra accepted this revision.Feb 3 2022, 9:31 AM
This revision is now accepted and ready to land.Feb 3 2022, 9:31 AM
michaelrj requested changes to this revision.Feb 3 2022, 2:18 PM

This is incorrect, should_round_up is called on decimal_point which is specifically signed because it represents the index of where the decimal point should be, relative to the digits. Specifically a negative decimal point represents a number that is less than 1. There is an if statement on line 115 to handle if roundToDigit is negative. While the code will still work if this change is made (any reasonable negative number will create an unsigned number greater than this->num_digits) it would make the code less correct.

This revision now requires changes to proceed.Feb 3 2022, 2:18 PM

This is incorrect, should_round_up is called on decimal_point which is specifically signed because it represents the index of where the decimal point should be, relative to the digits. Specifically a negative decimal point represents a number that is less than 1. There is an if statement on line 115 to handle if roundToDigit is negative. While the code will still work if this change is made (any reasonable negative number will create an unsigned number greater than this->num_digits) it would make the code less correct.

Isn't your reason exactly why this change is required? For, if roundToDigit was unsigned, roundToDigit < 0 will never be true?

My reason is that roundToDigit can be negative, and changing it to be unsigned would break that. The only line where should_round_up is called is line 367, and it's passed decimal_point, which is a signed integer which may sometimes be negative.

My reason is that roundToDigit can be negative, and changing it to be unsigned would break that. The only line where should_round_up is called is line 367, and it's passed decimal_point, which is a signed integer which may sometimes be negative.

As I read it, this change is making roudnToDigit to be of a signed type instead of an unsigned type. It is switching the type of roundToDigit from uint32_t (unsigned 32-bit integer) to int32_t (signed 32-bit integer).

michaelrj accepted this revision.Feb 3 2022, 2:37 PM

oops, you're right, I misread the patch. Sorry about that, LGTM.

This revision is now accepted and ready to land.Feb 3 2022, 2:37 PM