_Addresses_Add_offset and friends and strict aliasing

[Steven Johnson]

I have a number of concerns that

_Addresses_Add_offset and
_Addresses_Subtract_offset

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 (
  void       *base,
  uint32_t    offset
)
{
  return (void *)((char *)base + offset);
}

and

RTEMS_INLINE_ROUTINE void *_Addresses_Subtract_offset (
  void       *base,
  uint32_t    offset
)
{
  return (void *)((char *)base - offset);
}

for example:
_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 
the code.

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.

ie,
uint32_t* x

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 
inline them).

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.


Steven J