RFH: aliasing problems

[Thomas Doerfler]

Sergei,

Sergei Organov schrieb:

> 
> IMHO, the only practical fix for the networking code is disabling strict
> aliasing in compiler by means of -fno-strict-aliasing. I'm afraid that
> the amount of changes required to make the networking code to be
> aliasing-clean is too high to be practical.

There may be a different solution, as Peer Stritzinger has stated
earlier: The GCC-specific keyword "may_alias" can be used to mark any
data srtuctures, that may break the aliasing rules when accessed. So
maybe if this keyword is added to the structure definition of sock_addr,
we can directly mark accesses to the data type sock_addr as "outside the
aliasing optimization". This has many advantages:

- This will also take effect for the applications
- This will add "marks" in the RTEMS sources, where we have non-fixed
aliasing problems
- And it makes work/fail of the code independent from the compiler settings.
I think if we use this keyword, it should be encapsulated somewhere to
allow central customization when the keyword changes in a future
compiler release.

wkr,
Thomas.


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request