Re: [lwip-devel] Concern over strict aliasing and undefined behavior?

[Simon Goldschmidt]

Mike Pontillo wrote:

   If you clone the lwip git repository, you'll notice the first commit was in 2002. In that time period, if I remember correctly, strict aliasing compiler optimizations were bleeding edge. People were still figuring out what this new "restrict" keyword was and how to use it. Compilers weren't heavily optimized around strict aliasing at that time.

And if you add to that the fact that most embedded compilers are way behind the standard, it's even less probable that people actually thought about this back then.

On Mon, Oct 7, 2013 at 8:40 AM, Sam Caldwell <address@hidden> wrote:

[..] I've found lwip and a case that matches what I described above. Concretely, in the udp_input function in udp.c a void * is cast to a udp_hdr *.

My questions are:

1. Am I correct in diagnosing this as a violation of strict aliasing and therefore undefined behavior?

I thought this wasn't a violation because of using a void pointer. But then again, I never really looked into the issue: it seems like all (embedded) compilers I used lwIP with so far did not have a problem with how lwIP casts pointers.

2. If so, are the developers aware?

3. If so, what are the reasons for using this implementation?

There is an old thread in the archives relating to the subject, which seems to suggest that it is an issue:

http://lists.nongnu.org/archive/html/lwip-devel/2008-10/msg00012.html

I think you have to differ between multiple cases here: the one fixed in that archived message was taking one struct and letting another type point to it. This has been fixed.

However with the input/output functions, it's a different thing: data will not be written to memory and read back (aside from using the loop back connection maybe), but instead it's written there and sent out or received by the driver and read by the stack/application. In this case, what other options are left when implementing a stack with decent performance (I.e. not copying the data)? I can't think of one. Also, since the data is not reused but sent out, I think the chances of optimization breaking the code here is pretty low.

If you take strict aliasing as "not allowing different pointer types to the same data", you're good with the lwIP input/output functions, as (aside from the ethernet driver sending/receiving the buffer), the data is not otherwise referenced.

To sum it up, if you find more bugs like the one above, please let us know (I'm not sure there are none). Also, if you have an idea how to better implement it, you're welcome to share it! But as of yet, I don't know of any reported problem with this code, even if it might technically not cleanly follow the standard.

Simon