Inconsistent number format in listing after value conversion

Describe the bug This is a minor style issue. Immediate operands are displayed in lowercase in the listing. However when one uses the Convert context menu to convert the value to signed/unsigned hex, then the resulting value (which is actually an equate) will be displayed in uppercase, which is not consistent with the default listing hex number display format (0xffffffff vs 0xFFFFFFFF).

To Reproduce Steps to reproduce the behavior:

1. Import and open the attached test.exe file.
2. Right click on the PUSH -0x1 instruction at 0x40100d, and select Convert > Unsigned Hex.
3. The resulting number will be displayed in uppercase (0xFFFFFFFF), while another (unconverted) instruction at 0x401011 will use a lowercase 0xffffffff format.

Expected behavior Use the same letter case for the numbers in the listing and for converted values.

Screenshots

Attachments test.zip

Environment:

• OS: Linux Mint 19.3 Tricia
• Java Version: OpenJDK 12.0.2
• Ghidra Version: 9.1.2

Additional context It might be enough to remove toUpperCase() here, but as far as I can see this is also used for displaying memory data in the listing window which uses an uppercase h-suffixed format (e.g. FFFFFFFFh, instead of 0xffffffff), so that would affect that too unfortunately:

• https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/equate/ConvertToSignedHexAction.java#L40
• https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/equate/ConvertToUnsignedHexAction.java#L36

[emteere]

The dynamic labels and address values should be affected as well. Reading a number in lower case can look like camel case, so a label:

CALL FUN_180F2C3A5
CALL FUN_180f2c3a5

is easier to read and compare by eye in the upper case notation.

MOV EAX, C2345FABh
MOV EAX, 0xC2345FAB

MOV EAX, 0xc2345fab

The first and second case looks cleaner and the eye can see it is a number versus a label more quickly. The first case has one fewer character. The third could be more easily mistaken for a user entered label and could be harder on the eyes for those without 20/20 vision or a 4K screen.

Input formats all must handle 0x0, 0h, upper or lower case notation although parsing both gets messier especially in grammers like sleigh, and some places may only support the 0x0 formats. But sleigh doesn’t necessarily need to change.

Copy and paste of any number format needs to be supported so that a number can be copied and used anywhere, say in the GOTO dialog without needing to add an ‘h’, carefully selecting the number in front of the ‘h’, or adding a ‘0x’ to the front.

Maybe an option to upper case all number displays, and an option to put the ‘h’ after or the ‘0x’ in front? As you mention the real issue is consistency.

[fenugrec]

Another issue is what do most assemblers accept? 0x, or ‘h’ at the end?

To add to the mix, some archs have less usual hex formats :

• HCS12/CPU12 has a “$” prefix
• PIC MPASM will accept both 0x prefix and the odd H’hex_digits’ form

I prefer 0x prefix myself, but I’m fairly confident this can turn into a religious argument comparable to indent styles. But I think everybody will agree that consistency would be desirable.