x86: uint32_t keeps changing to 2 bytes in function signature

Describe the bug When editing a function, uint32_t, when formed by AX:BX or CX:DX, keeps changing to 2 bytes.

To Reproduce Steps to reproduce the behavior:

1. Disassemble TELEN.EXE (from https://www.dosgamesarchive.com/download/telengard/)
2. Go to 1000:ac13. This is the idiv32 function.
3. Attempt to edit its function signature to uint32_t __cdecl16near idiv32(uint32_t x, uint32_t y) with custom storage, either in the decompilation window or in the listing window. You can initially set the storage for x to AX and BX, and for y to CX and DX. However, any attempt to set the return type to uint32_t and its storage to AX and BX will result in a “too much storage” error, because for some reason Ghidra thinks that a return type of uint32_t is only 2 bytes.

Expected behavior A return type of uint32_t is 4 bytes, and its storage can be allocated to two 16-bit registers.

Screenshots

Environment (please complete the following information):

• OS: Windows 10
• Java Version: 11.0
• Ghidra Version: 9.0

[d-millar]

Totally makes sense, and I think we’re basically on the same page. Apologies for not checking out the Digital Mars code immediately - interesting example, definitely not the norm.

You make a good case for adding the C99 types as Builtins. That might avoid a lot of general confusion. We have things that are obviously close to being equivalent, e.g the DWord and UnsignedInteger Builtins are defined to be 4 bytes in length (admittedly, not necessarily 32 bits). The question, I think, is whether adding the C99 types as Builtins will create confusion or conflict with defined types with identical names, but obviously for things like uint32_t with a pretty clear definition adding them might be reasonable.

Will raise this with the team and get back to you. Thanks!

Follow on: going to correct me own comment above - the UnsignedInteger Builtin is dynamic (vice the DWord builtin). Am definitely making your point about how confusing this is.

I’m going to re-submit this as an enhancement, so we can continue the discussion there!

[Godzil]

Well for unix.org now it is working. I was getting some sort of a temporary page basically saying “nothing there”, so you can forget about that, not sure what happened.

1. DigitalMars C/C++ stdint.h can be found here: https://github.com/DigitalMars/dmc/blob/master/include/stdint.h

And you can find here:

/* Exact sizes */
typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef short int16_t;
typedef unsigned short uint16_t;

typedef long int32_t;
typedef unsigned long uint32_t;

And this compiler is fairly modern (aka still maintained) and support DOS16, DOS32, WIN16 and WIN32. I don’t think so it support 64bit mode, but that’s not really it’s purpose anyway.

This stdint.h is of course valid only for Digital Mars C.

1. I do agree for generic type like short/int/long but type like uintXX_t should really be fixed in size; not sure how Ghidra is working on that point, but if it has its own internal types with fixed size the intXX_t and uintXX_t should be part of the non compiler dependent one.

I’m not sure to be really clear in my explanation:

C99 clearly define that each of intXX_t and uintXX_t must have a strict size to have types that are not compiler and environment dependent. And as they are not really native type the compiler maker have to set them using typedefs in a way which for that specific compiler make sure they mean exactly what they say depending on how the compiler treat char/short/int/long. On the other hand Ghidra should NOT do the same and not rely on a compiler set of header to set theses specific types, so if a user who probably don’t know what compiler was used these specific set of C99 types should not have random size because it happen that Ghidra use typedef internally and the current architecture says that int32_t == int and int == 16 bit so int32_t == 16bits that’s non sense.

Of course if you parse header that are not meant for an architecture and then get your types wrong that a different story (and would cause issue with real compiler), but C99 type that are standardizes with specific definition, Ghidra should treat them as Builtin types and not defined types.

Hope it makes more sense…