RFH: aliasing problems

[Till Straumann]

Welcome to the world, ralf :-)

This way of casting struct sockaddr * and struct sockaddr_xxx *
(xxx for the address family) is done by every application using sockets
(and they'll all get the type-punned pointer warning).

I would hope that the
struct sockaddr * is eventually cast back to the correct/original type
(based on the address family).

However, who knows what's going on in the guts of networking.
Our old BSD stack was definitively not written with the alias rule
in mind...

BTW: newlib is neither. It implements memcpy doing register-wide
data transfers. This is impossible to code in strict C99, AFAIK.

The alias rule is fine for abstract high-level programming but it is 
inappropriate
for low-level programming where you *have* to deal with the
representation of objects and make assumptions about device registers,
byte-ordering and the like...

Here's another proposition:

We could try to make the RTEMS APIs strictly C99 compliant
so that applications could be compiled with -fstrict-aliasing 
-Wstrict-aliasing
but we'd always turn it off for RTEMS proper.

T.

Ralf Corsepius wrote:
> Hi,
>
> I've filed 3 PRs on pretty massive aliasing problems, gcc even diagnoses
> itself:
>
> ftpd.c:
> https://www.rtems.org/bugzilla/show_bug.cgi?id=1184
>
> rtems_glue.c:
> https://www.rtems.org/bugzilla/show_bug.cgi?id=1185
>
> if_ethersubr.c:
> https://www.rtems.org/bugzilla/show_bug.cgi?id=1186
>
> All of them affect all targets and would require careful asm analysis
> and careful fixing.
>
> Any help appreciated. I don't think, I'll be able to fix them any time
> soon.
>
> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>