zephyr: Zephyr types incompatibilities (e.g. u32_t vs uint32_t)
Hello all! I have a question regarding the usage of u32_t with newlib.
So the problem is that as far as I understand all the variables in the drivers should use u32_t, at the same time, the ext files (e.g. HALs) are NOT ported to use these types and still use uint32_t.
What is the correct approach to calling HAL functions in the driver to avoid warnings with different C libs?
Should I simply avoid using u32_t in that cases and cast directly to uint32_t in the driver?
Here is an example of such call: https://github.com/zephyrproject-rtos/zephyr/blob/a313e5c74f01750411bf65e9903278f913328585/drivers/ethernet/eth_sam_gmac.c#L99
The function is defined as follows: https://github.com/zephyrproject-rtos/zephyr/blob/a313e5c74f01750411bf65e9903278f913328585/ext/hal/cmsis/Include/core_cm7.h#L2453
It generates the following warning when newlib is used:
ext/hal/cmsis/Include/core_cm7.h:2453:22: note: expected ‘uint32_t * {aka long unsigned int *}’ but argument is of type ‘u32_t * {aka unsigned int *}’
So the typedefs are obviously different.
Thank you for all your insights!
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 22 (12 by maintainers)
Commits related to this issue
- drivers: eth: gmac: Cast to type expected by HAL This is needed to avoid compilation warnings when using both the built-in libc and newlib. The warnings were caused by typedefs incompatibilities. Th... — committed to antmicro/zephyr by tgorochowik 6 years ago
- drivers: eth: gmac: Cast to type expected by HAL This is needed to avoid compilation warnings when using both the built-in libc and newlib. The warnings were caused by typedefs incompatibilities. Th... — committed to zephyrproject-rtos/zephyr by tgorochowik 6 years ago
Not sure what you mean. They are by-design redundant with uint32_t. It’s just a different naming convention for the same concept.
E.g. it would be valid for Zephyr to do:
typedef uint32_t u32_t;
AFAICT
Right, I would suggest changing both of them then, assuming there are no unexpected consequences.
Using %u for unsigned formatting seems acceptable to me. %d is for signed integers.
As far as I can read the C standard we may eventually encounter a toolchain that uses 16 bits for “unsigned int” and break uint32_t as that is perfectly valid behaviour. So this change may fix future problems as well.
– http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
I may be misunderstanding something though.
A very large reason why it’s currently an unsigned int is because people wanted to use
%uin printf format code instead of the more cumbersome (but correct)...%" PRI_u32 "...edit: %u, not %d