_Addresses_Add_offset and friends and strict aliasing

[Sergei Organov]

Steven Johnson
<sjohnson at sakuraindustries.com> writes:

> 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.

I don't think they aren't compliant. One needs to investigate every
particular use of these routines in the rest of code and make decision
based on the usage.

>
> 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.

Once again, what type of object is there at the final address? If it's
an instance of Thread_Control and is accessed through Thread_Control*
pointer, then it's fine. If not, there could be aliasing problem.

>
> _Address_Add_offset is used to alias a Objects_Name* into a 
> Objects_Control** in objectextendedinformation.c

The same remark as above. It's a probable place of aliasing violation,
but you didn't show the violation itself.

>
> 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,

Exactly.

> as the value to add or subtract could be 0, and so it is just creating
> a pointer alias.

Changing pointer type doesn't violate aliasing rules by itself.

Not changing pointer type definitely doesn't violate aliasing rules, so
if you convert result of the function back to the same pointer type
you've passed, you even have no chances to violate aliasing rules
because of subtracting an offset, be it 0 or any other value.

> 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.

It's irrelevant to aliasing rules if pointer arithmetic is used or not.

[...]

> 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.

I still don't see conformance problem in those two places from the
information you've provided. Though I didn't look at the actual code to
figure out if there are indeed aliasing problems there.

-- Sergei.