6

Im asking my self, can i use the BSD sockets with strict aliasing on, without getting undefined behaviour by compiling with gcc?

bind(sdListen, (struct sockaddr*)&sockaddr_inIdentifier, sizeof(sockaddr_inIdentifier))

This line of code breaks the strict aliasing rule as far as i know (and gcc gives me the same warning). so is there a plan b, of using the sockets in O3 mode without turning strictaliasing of? And of course without breaking the rule? or do i have to get an own socket system running that will be runnable on all systems/compilers?

dhein
  • 6,431
  • 4
  • 42
  • 74

1 Answers1

6

The cast itself in that line does not break the strict aliasing rule. The rule is only broken if the implementation of bind() dereferences that pointer without converting it back to the right type.

Any strict aliasing problems there are problems for the implementer of bind(), not the user.

caf
  • 233,326
  • 40
  • 323
  • 462
  • So there is no way of using the Sockets while respecting the strict-aliasing rule? What results in, i cant let the compiler optimate my source code, without the risk of undefined behaviour? – dhein Aug 01 '13 at 09:42
  • @Zaibis: *Using* the BSD Sockets does not require breaking the strict aliasing rule. Furthermore the implementer of your platform's sockets API has presumably gone to the trouble to ensure that the implementation has defined behaviour, too. – caf Aug 01 '13 at 09:50
  • Well i tryed it now on the freeBSD10.0 9.1 and Debian 6. dunno... the result was the same when compiling with gcc. So did i get you right, whats happening inside Bind() is deciding about the cast will break the rules or not? and from outside gcc just tells me that it could break the rules? so i cant compile a code of a BSD socket app with treat warnings as errors, because there is no way of avoiding this warning? – dhein Aug 01 '13 at 11:02
  • @Zaibis: Yes, that's right - the warning is telling you about a *potential* problem. Recent versions of glibc at least use a transparent union to define the `struct sockaddr *` arguments which avoids the warning. – caf Aug 01 '13 at 11:46
  • But all the research I did, was pointing to the fact that already the cast from &sockaddr_in to struct sockaddr* is a breaking of the rule, what is resulting in undefined behaviour, so even if the API of my platform is just casting it back to the type of the memory adress, it wouldnt change the fact that theoretical, there could alrdeady be anything else inside the adress, because its not defined whats going to happen.... or did I get that wrong after all the research i did the last days?:x – dhein Aug 01 '13 at 17:53
  • @Zaibis: Merely casting an address from one struct type to another does not have undefined behaviour. – caf Aug 01 '13 at 21:57
  • But aren't there cases, where a compiler will optimize out code because of those casts. With the reason that they are illegal? Or is it just illegal, in the moment i start working with the value of an not strict aliasing pointer? – dhein Aug 02 '13 at 08:07
  • @Zaibis: I don't know how much more clearly I can say it - the cast itself is not illegal, and a compiler can't optimize out the code because of it. The "strict aliasing" rule is that an object must be accessed through an lvalue expression with the right type, so it is all about the subsequent access to the underlying object and not the pointer conversion. – caf Aug 02 '13 at 22:36