Ensure correctness of formatted output conversion #169
+184
−76
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ChAoSUnItY
reviewed
Dec 1, 2024
lib/c.c
Outdated
| * Finally, the remaining 2 bits are processed after | ||
| * the loop. | ||
| * */ | ||
| for (int i = 0; i < (sizeof(int) << 3) / 3; i++) { |
There was a problem hiding this comment.
Perhaps you can lift the rhs expression of condition expression out of loop to squeeze last bit of performance?
ChinYikMing
reviewed
Dec 2, 2024
tests/driver.sh
Outdated
| 0" | ||
|
|
||
| try_output 0 "$fmt_ans" << EOF | ||
| void print_conversion(int num) { |
There was a problem hiding this comment.
nit: use printf_conversion for consistency.
The original implementation of __str_base16(), which converts integers to hexadecimal strings, causes errors when processing negative integers. It produces redundant 'f' characters at the beginning of the converted string due to sign extension and results in unexpected output when calling printf() or sprintf(). Therefore, this commit fixes it and ensure correct conversion.
The implementation of __str_base8() produces incorrect conversions when handling negative integers. For example, a 32-bit negative integer '0xfffff204', it will produce '7' at the most significant digit due to sign extension. However, it should produce '3' by using the leftmost 2 bits only. Therefore, this commit modifies the conversion process to fix the mentioned problem.
The implementation of __format() produces incorrect results
when using field width and flag characters.
For example, consider the following printf calls, where the
prepended characters are placed in incorrect positions.
printf("%#12x\n", 0xff00cde1) --> "0x ff00cde1\n"
printf("%#12o\n", 0x1000c) --> "0 200014\n"
printf("%12d\n", -3580) --> "0000000-3580\n"
Thus, this commit improves __format() to ensure correctness
and to make the results consistent with GCC, and adds a test
case to validate the changes.
|
Thank @DrXiao for contributing! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider the following code printing the several formatted integers:
I found some incorrect results for certain outputs when using specifier, field width and alternate form:
1. Incorrect conversion from integers to hexadecimal strings
Consider a 32-bit integer
-16724511(0xFF00CDE1in hexadecimal), if usingprintf()with the formatted string"%#12x", it outputsffffff00cde1, and the result has redundentfcharacters. However, because the integer is just 4 bytes, the result should beff00cde1containing 4 whitespace characters.2. Incorrect conversion from integers to octal strings
As the previous point, consider the negative integer
-3580(0xFFFFF204in hexadecimal), it produces77777771004when using"%o"to print this integer.Because the function accepts a 32-bit integer, the most significant digit of the octal should be obtained by the leftmost 2 bits only, but the original implementation doesn't consider this point and produce incorrect results.
Thus, the correct result is
37777771004, which obtains3from the leftmost 2 bits of the integer.3. Prepended characters may be placed in incorrect positions
When using field width and flag characters, it may output unexpected strings for certain cases.
printf("%#12x\n", 0xff00cde1)-->"0x ff00cde1\n"printf("%#12o\n", 0x1000c)-->"0 200014\n"printf("%12d\n", -3580)-->"0000000-3580\n"Conclusion
Through the given test code, the current built-in C library has been found to have the above issues, so this pull request resolves them and ensures correctness when using formatted output conversion.