_Addresses_Add_offset and friends and strict aliasing
sjohnson at sakuraindustries.com
Fri Dec 15 00:53:14 CST 2006
I have a number of concerns that
are not compliant with the strict aliasing rules of C99, and so may
generate bad (or worse, inconsistent from target to target and optimised
or not) code under GCC with -O2 or -fstrict-aliasing enabled.
It is in address.inl (and there is a macro form as well), it is defined as:
RTEMS_INLINE_ROUTINE void *_Addresses_Add_offset (
return (void *)((char *)base + offset);
RTEMS_INLINE_ROUTINE void *_Addresses_Subtract_offset (
return (void *)((char *)base - offset);
_Address_Subtract_offset is used to alias a Chain_Node* to a
Thread_Control* in threadmp.c.
_Address_Add_offset is used to alias a Objects_Name* into a
Objects_Control** in objectextendedinformation.c
These are just 2 cases I have picked out, there are many many more in
I don't think it matters that pointer arithmetic is being performed, as
the value to add or subtract could be 0, and so it is just creating a
pointer alias. Further, I don't read that there is any exception to
pointer aliasing if pointer arithmetic is used. The C99 spec certainly
makes no exception for aliasing if pointer arithmetic is used.
y = x+7
y should be a uint32_t*. If it is cast to assign to y, that is a
pointer alias of the pointer (x+7).
It also seems to me that this could have vastly different behaviour
depending on whether these routines are in fact inlined or not (marking
them as inline is just a hint to the compiler it is not compelled to
I am not filing a PR on these, as I think the code is fine and
reasonable. But it certainly seems to be a problem as against C99, if
C99 conformance is important. If that is an issue them a PR on these
and all places that use them should probably be raised.
More information about the rtems-users