Is your feature request related to a problem? Please describe.
While working with ThreadX on AArch64, I noticed that ULONG is defined as a 32-bit type.
This can be surprising, as in many other ecosystems , libraries and vendor SDKs (e.g., Xilinx/AMD xil_types.h), ULONG typically maps to unsigned long, which is 64-bit on LP64 platforms.
This discrepancy can lead to:
- incorrect assumptions about type size
- portability issues when integrating with external libraries
- subtle bugs when developers assume
ULONG matches the native word size
As 64-bit architectures become more common in embedded systems, this ambiguity may become increasingly problematic.
Describe the solution you'd like
Make the fixed-width nature of ULONG explicit in the public API. For example:
- introduce a clearly named type such as
ULONG32
- keep
ULONG as a legacy alias for backward compatibility
- gradually migrate API usage from
ULONG to ULONG32 where appropriate
This would:
- preserve ABI and backward compatibility
- improve clarity for new users
- reduce ambiguity across platforms
Impact
This change primarily improves API clarity and developer experience.
It can be implemented in a backward-compatible way without introducing breaking changes.
Describe alternatives you've considered
Introducing a more conventional fixed-width naming scheme (e.g., UINT32, U32)
However, this may conflict with existing naming conventions or reduce consistency with the ThreadX style.
Additional context
Although this refactoring may touch many parts of the codebase, addressing the ambiguity early can help prevent future portability issues and reduce long-term technical debt.
Is your feature request related to a problem? Please describe.
While working with ThreadX on AArch64, I noticed that ULONG is defined as a 32-bit type.
This can be surprising, as in many other ecosystems , libraries and vendor SDKs (e.g., Xilinx/AMD
xil_types.h),ULONGtypically maps tounsigned long, which is 64-bit on LP64 platforms.This discrepancy can lead to:
ULONGmatches the native word sizeAs 64-bit architectures become more common in embedded systems, this ambiguity may become increasingly problematic.
Describe the solution you'd like
Make the fixed-width nature of
ULONGexplicit in the public API. For example:ULONG32ULONGas a legacy alias for backward compatibilityULONGtoULONG32where appropriateThis would:
Impact
This change primarily improves API clarity and developer experience.
It can be implemented in a backward-compatible way without introducing breaking changes.
Describe alternatives you've considered
Introducing a more conventional fixed-width naming scheme (e.g.,
UINT32,U32)However, this may conflict with existing naming conventions or reduce consistency with the ThreadX style.
Additional context
Although this refactoring may touch many parts of the codebase, addressing the ambiguity early can help prevent future portability issues and reduce long-term technical debt.