| commit | ec62fab6330d356497514144a7284901b081247e | |
| author | Doug Torrance <dtorrance@piedmont.edu> | |
| Thu, 30 Aug 2018 02:59:57 +0000 (29 22:59 -0400) | ||
| committer | Carlos R. Mafra <crmafra@gmail.com> | |
| Thu, 30 Aug 2018 03:14:02 +0000 (29 23:14 -0400) | ||
| tree | ce9f30a59daffaecf6c143aab5c96ce27892e3de | treesnapshot (tar.gz zip) |
| parent | 1d813d4434a7e9b082e432750b92597cb5e8055a | commitdiff |
wmcalc: Null-termitate display string when clearing.
Often, the number currently being displayed has more than 10 digits.
However, when clearing the display, only the first 10 digits were cleared.
When a new number was entered, it would be prepended to any digits that
weren't cleared. This behavior was invisible to the user, causing
incorrect calculations, e.g., Debian bug #564173:
1814 / 720 * 300 -> 7568.41111
But the correct answer is 755.833333.
The problem was that when the display was cleared, the string that stores
this number was not null-terminated. Indeed, 1814 / 720 gives us
2.519444444 (6 4's), but only 2.51944444 (5 4's) is displayed. When we
begin to multiply by 300, the final 4 remained, and so we really were
multiplying by 3004.
Often, the number currently being displayed has more than 10 digits.
However, when clearing the display, only the first 10 digits were cleared.
When a new number was entered, it would be prepended to any digits that
weren't cleared. This behavior was invisible to the user, causing
incorrect calculations, e.g., Debian bug #564173:
1814 / 720 * 300 -> 7568.41111
But the correct answer is 755.833333.
The problem was that when the display was cleared, the string that stores
this number was not null-terminated. Indeed, 1814 / 720 gives us
2.519444444 (6 4's), but only 2.51944444 (5 4's) is displayed. When we
begin to multiply by 300, the final 4 remained, and so we really were
multiplying by 3004.
| wmcalc/wmcalcfunc.c | diffblobblamehistory |