| Summary: | [Feature request] Change octal prefix to "0o" | ||
|---|---|---|---|
| Product: | [Applications] kcalc | Reporter: | Jelle <snellejelle99jb> |
| Component: | general | Assignee: | Gabriel Barrantes <gabriel.barrantes.dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | gabriel.barrantes.dev, guimarcalsilva, le5h |
| Priority: | NOR | ||
| Version First Reported In: | 24.05.0 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/utilities/kcalc/-/commit/03d25ed2d731a3e0266395d20bd01d01fd41a2c0 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | Screenshots | ||
This might be related to https://bugs.kde.org/show_bug.cgi?id=485319 Inputting 00AB and pressing '=' results in 0 for me. "010 + 1" and "1+010" also have these issues and results in "1001" just "01" strangely does not present this issue. "01 + 1" results in "10" as expected. It is interpreting the string "0101" as the OCTAL value "101", which is 64 decimal, or 0100 0001 binary. (In reply to Evan Teran from comment #3) > It is interpreting the string "0101" as the OCTAL value "101", which is 64 > decimal, or 0100 0001 binary. So this means its a confirmed bug? If not why? Its also doing this in decimal 020 + 020 results in 32. The problem seems to originate here: https://invent.kde.org/utilities/kcalc/-/blob/master/kcalc_parser.h?ref_type=heads#L59 The prefix for an octal number should probably be "0O" or "0o". To me it seems extremely confusing to have "0" be the octal prefix. Especially to users unfamiliar with number systems different from regular decimal. I wouldn't say it is a "bug" as it is working as expected, but perhaps a mis-feature since you're not the first to report this behavior as undesirable, for example, 020 in octal *is* 16 decimal. The reason for this behavior is that conventionally the following prefixes mean: 0xNNN -> hex 0bNNN -> binary 0NNN -> octal 0oNNN -> a new, less ambiguous notation for octal, but not universally prevalent The reason for this behavior is that people copy and paste numbers and previously we've had bug reports where people said "I pasting 0x1234 in decimal mode results in NaN!" So there unfortunately seems to be no behavior that will be intuitive for everyone. Some people want it to respect the source input format, some want to respect the chosen mode. All of that being said, while I was the maintainer for kcalc 20 years ago, it's been a LONG time since I've even looked at the code. I just wanted to chime in since I saw the email and thought I could shed light on WHY it is happening so that other contributors who are more active will know where to start. (In reply to Evan Teran from comment #6) > I wouldn't say it is a "bug" as it is working as expected, but perhaps a > mis-feature since you're not the first to report this behavior as > undesirable, for example, 020 in octal *is* 16 decimal. > > The reason for this behavior is that conventionally the following prefixes > mean: > > 0xNNN -> hex > 0bNNN -> binary > 0NNN -> octal > 0oNNN -> a new, less ambiguous notation for octal, but not universally > prevalent > > The reason for this behavior is that people copy and paste numbers and > previously we've had bug reports where people said "I pasting 0x1234 in > decimal mode results in NaN!" So there unfortunately seems to be no behavior > that will be intuitive for everyone. Some people want it to respect the > source input format, some want to respect the chosen mode. > > All of that being said, while I was the maintainer for kcalc 20 years ago, > it's been a LONG time since I've even looked at the code. I just wanted to > chime in since I saw the email and thought I could shed light on WHY it is > happening so that other contributors who are more active will know where to > start. I could understand this in the case for Hex and binary. But I have never seen a calculator that accepts 0 as a prefix for octal. In that case is would suggest the following: * Remove the octal prefix from simple, science and statistic mode altogether. (People using these modes probably aren't using octals) * When in numeral system mode: Disable the octal prefix when binary, hex, or decimal is selected. (You already can't use the hex prefix when binary is selected and vice versa) *** Bug 465200 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/utilities/kcalc/-/merge_requests/117 Git commit 03d25ed2d731a3e0266395d20bd01d01fd41a2c0 by Gabriel Barrantes. Committed on 19/07/2024 at 19:48. Pushed by gabrielbarrantes into branch 'master'. Change octal prefix from "0" to "0o" Leading 0s will be ignored in all bases for all numeric inputs. Related: bug 488728 M +12 -4 autotests/kcalc_parser_core_test.cpp M +1 -1 kcalc_display.cpp M +8 -4 kcalc_parser.cpp M +2 -1 kcalc_parser.h https://invent.kde.org/utilities/kcalc/-/commit/03d25ed2d731a3e0266395d20bd01d01fd41a2c0 *** Bug 490851 has been marked as a duplicate of this bug. *** |
Created attachment 170017 [details] Screenshots SUMMARY When in numeral system mode. Inputting a binary number starting with a 0 results in an output that is shifted 2 to the left. STEPS TO REPRODUCE 1. Start Kcalc and enter numeral system mode 2. Select the "bin" checkmark 3. Type "10" and press '='. 4. Verify that the result is "10" in bin and "2" under hex. (As expected :)) 5. Clear the registers by pressing the 'C' button. 6. Type "010" and press '='. 7. Verify that the result is "1000" in bin and "8" under hex. (Not good :(( 8. Clear the registers by pressing the 'C' button. 9. Type "011" and press '='. 10. Verify that the result is "1001" in bin and "9" under hex. (Not good :(( I have repeated this with numbers of different lengths and the result is always the same. OBSERVED RESULT First 1 after a leading 0 is shifted 2 positions left in binary input mode. EXPECTED RESULT Leading 0's are stripped from the input and the first 1 is not shifted. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Linux 6.6.32-1 Manjaro (available in About System) KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Graphics platform: Wayland