Updated Memory Scanner to use sized hexadecimal in results and manual watches.
Enforced Halfword,Word address settings so that it's a valid word or halfword that is being watched.
* Changed debugger "Enter memory address" to accept hex only
The "Enter memory address" prompt by default expects a decimal address unless it's preceded by 0x. Or it expects an number starting with 0 is an octal.
The disassembly address should be hexadecimal regardless as that is how it it displays the address.
Also changed it so that it changes any address entered to be divisible by 4 as there was an observed issue that would cause the disassembly addresses to get locked to a address that was not divisible by 4
* Translation updates for Debugger memory address change
Updated the three translation files that mentioned the original "Invalid address. It should be in hex" string.
* Changed debugger "Enter memory address" to accept hex only
UPDATE TO PR #1316
The "Enter memory address" prompt by default expects a decimal address unless it's preceded by 0x. Or it expects an number starting with 0 is an octal.
The disassembly address should be hexadecimal regardless as that is how it it displays the address.
Also changed it so that it changes any breakpoint or disassembly address entered to be divisible by 4 as there was an observed issue that would cause the disassembly addresses to get locked to a address that was not divisible by 4 and a breakpoint address that is not divisible by 4 would never be hit.
If we don't skip past the following separator when the destination
is empty, then `./file` gets canonicalized as `/file`.
Also, consider the case where we end up with an empty string (for
example, from `foo/..`). Canonicalize this as `.`.
The previous implementation had a few issues in certain edge cases:
- If the path contained no '/' or '\', then the string_view constructor
is called with a count that exceeds the length of the string
(effectively `title_end - (char *)0`, which is undefined behavior,
at least in C).
- If the only '/' was the filesystem root, the last character of
the title was truncated, and the '/' remained. For example,
"/title.bin" resulted in "/titl".
- At least in C, it is undefined behavior to use the the < operator
with a null pointer, which is done in std::max if the path did
not have both '/' and '\'.
The first issue results in a std::bad_alloc exception on my machine.
