Enums imported from C headers silently discard Negative explicit values

Describe the bug When importing a C header file containing an Enum which defines at least one of its values as an explicit Negative number, that number is silently ignored, causing incorrect values to be assigned to subsequent entries.

To Reproduce

1. Create a C header file containing the following definition: enum my_enum { invalid = -1, zero, one, two, five = 5, six };
2. Use the “Parse C source” function to import the header file.
3. In the Data Type Manager, locate “my_enum” and Edit it.
4. Observe that the entry “invalid” has a value of 0, “zero” is 1, “one” is 2, and “two” is 3. “five” is properly set to 5 (as its explicit value was positive), and “six” was correctly assigned to 6.

Expected behavior The enum entries should have been assigned as “invalid” = -1 (or 0xFFFFFFFF), “zero” = 0, “one” = 1, “two” = 2, “five” = 5, and “six” = 6. Alternatively, “Parse C Source” should have thrown an error and aborted.

Screenshots N/A

Attachments N/A

Environment

• OS: Windows 7 SP1 x64
• Java Version: 11.0.2
• Ghidra Version: 9.0.2

[tombsar]

This is still an issue in 9.0.4. Ghidra internally treats enums as an unsigned data type, which is a significant oversight imo. A hacky fix would be to modify the enum GUI and source parser to accept negative decimal numbers and convert them to the equivalent two’s complement hex value, but that would still break if the user changes the size (number of bytes) of the type.

[astrelsky]

@quietust if the builtins enum type is unsigned, then that is likely the cause. I have been having one hell of a time overriding the built-in datatypes, specifically the size of a long. Even when defined as 8 in the cspec files things such as the c header parser don’t care and apply the builtins type anyway. Anything that tries to conflict with the builtins seems to cause s headache. There should be an easy way to override them.