OSMemCreateAssumes 32bit pointers

[heyneman]

In the call to OSMemCreate(), if arg checking is enabled, the pointer to the start of the partition is cast to an integer in order to verify its aligned to store pointers.

When I compile this on a 64bit system I get compiler warnings about the cast to a smaller type. uC-CPU defines an OS_ADDR type, which would be ideal to use here, but uC-OS2 isn't required to use it. My workaround so far has been to add a similar typedef in os_cpu.h (along with the others like INT32U currently used in the cast).

To reproduce; compile os_mem.c on Ubuntu 18.04 (64bit) using gcc 7.5.0.

uC-OS2/Source/os_mem.c

Line 106 in 28c58eb

if (((INT32U)addr & (sizeof(void *) - 1u)) != 0u){ /* Must be pointer size aligned */

[forg0ne]

Thank you for reporting this.
Unfortunately, there is no easy way for us to resolve it.
We are reluctant to include a dependency on uC-CPU for legacy support reasons.
Neither can we use INT64U because it is only defined for a couple of ports.

Because this is an edge-case, the best approach in our opinion is to document it as an errata with a workaround for those who encounter it.

[forg0ne]

Errata for uCOS-III can be found here.

[heyneman]

@forg0ne Just for my understanding, why would adding a typedef <...> OS_ADDR line in os_cpu.h (per port) not be an easy way to resolve it?

Then OSMemCreate() can use that type internally rather than assuming 32b.

[forg0ne]

@heyneman There are a couple of issues that hold us back from adding this change:

1. The sheer number of ports makes it infeasible to test the change for each port.
2. We would be changing a function signature for a product that has a long history of use in safety-critical applications. This is something we would prefer to avoid if possible due to the impact it may have on certification.

The vast majority of architectures we target are 32-bit. For the exceptions, such as ARM64, the workaround can be applied on a case-by-case basis by the end-user.