A minor bug shows up when trying to go to a given hexadecimal offset.
This only occurs when the address is copied-and-pasted from an external application (like the commonly-used KCalc).
Then the input Ctrl+G dialog does not filter out the '0x ' part of the address, which inactivates the go-to capability.
BC does not crash yet does not go to the given address either.
The bug is related to the fact that legitimate address input is only decimal-like (i.e. without the '0x' prefix), even for hexadecimal numbers, which is a bit odd although not a bug in itself. Yet the validating input filter of the Ctrl+G dialog, which filters out the '0x' part, only works for keyboard input. For copy-and-paste input, it does not seem to apply. So that, in the copy-and-paste case, the input is not properly processed when clicking OK.
Untested on Windows. Screenshot attached.
This only occurs when the address is copied-and-pasted from an external application (like the commonly-used KCalc).
Then the input Ctrl+G dialog does not filter out the '0x ' part of the address, which inactivates the go-to capability.
BC does not crash yet does not go to the given address either.
The bug is related to the fact that legitimate address input is only decimal-like (i.e. without the '0x' prefix), even for hexadecimal numbers, which is a bit odd although not a bug in itself. Yet the validating input filter of the Ctrl+G dialog, which filters out the '0x' part, only works for keyboard input. For copy-and-paste input, it does not seem to apply. So that, in the copy-and-paste case, the input is not properly processed when clicking OK.
Untested on Windows. Screenshot attached.
Attached Files
Comment