RFH: aliasing problems

[Thomas Doerfler]

Ralf,

Ralf Corsepius schrieb:
> 
> Neither Linux nor Solaris-2.7 exhibit this behavior with their sockaddr*
> types and gcc-4.1.x. FreeBSD and RTEMS do.
> 
> 
> Linux, Solaris and Cygwin have
> 
> struct sockaddr {
>   sa_family_t sa_family;
>   char sa_data[14];
> };
> 
> struct sockaddr_xx {
>   sa_family_t sa_family;
>   ....
> };


> 
> 
> FreeBSD and RTEMS have:
> 
> struct sockaddr {
>   unsigned char	sa_len;
>   sa_family_t sa_family;
>   char sa_data[14];
> };
> 
> struct sockaddr_xx {
>   unsigned char sa_len;
>   sa_family_t sa_family;
>   ...
> };
> 
> 
> So, how does this match with strict-aliasing rules?
> 

When I look at the above structures, I think they are definitively
incompatible regarding the aliasing rule. If some kernel code converts a
sockaddr_xx pointer to a more general sockaddr pointer, C99 assumes that
they do not alias. I do not see a principal difference to the
FreeBSD/RTEMS definitions of these structures, except we have an
additional general element "sa_len".

When I look into the kernel makefiles for my linux system (2.6.13), the
kernel obviously is built with "-fno-strict-aliasing". Maybe this is not
needed for all (clean) applications, but then the application code
should use either "struct sockaddr" or "struct sockaddr_xx", but not
intermix pointers to both types of structures.

Once again, I see no basic difference in the structure implementations.
Both implementations make the two structures incompatible concerning
aliasing.

wkr
Thomas.


> Ralf
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users


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