3 ms·

No, he's wrong. Aliasing between union members has never been defined behavior. It just happened to work. Now that optimizers are getting better, these long-st

No, he's wrong. Aliasing between union members has never been defined behavior. It just happened to work. Now that optimizers are getting better, these long-standing issues are starting to surface in the real world. This is no different from when programmers do something dumb like j = i++ * i++; which works until it doesn't. Or worse, someone runs Stroutroup's book through a static code analyzer and finds a wall of errors so the language is changed [1]. Code around it and move on -- as in the patch mentioned. [1] https://en.cppreference.com/w/cpp/language/eval_order https://en.cppreference.com/w/cpp/language/eval_order

waynecochran 8y ago
It's gcc defined behavior. Not the BS (his words) C standard behavior.
berti 8y ago
Did you actually read what he wrote? He agrees that's what the standard says, thus the standard is not workable in reality, so he goes with GCC's (defined in documentation) implementation. It doesn't "just happen to work" in GCC, it deliberately works, and GCC is the only compiler the core kernel devs care about (see ASM goto).
- cjensen 8y ago
  Sure. And that's a terrible reason. First, he's binding Linux to gcc forever. I've made that mistake and let me tell you, it's a mistake with surprisingly few benefits. A couple of asms and gccisms? Easily replaced. Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic. Third, "the standard is not workable in reality" is simply wrong. I work on low-level systems. I somehow manage to work with devices and networks on a day-to-day basis without relying on this. Ultimately it comes down to this: Linus put his faith in something which was explicitly removed from C 30 years ago. The writing has been on the wall for about 10 years now[1]: Good optimizers are going to do away with this mis-feature. Time to start adapting to reality. [1] http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/ http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al...
  - yoklov 8y ago
    > Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic. Type punning through a union works on GCC without -fno-strict-aliasing, and is documented in multiple places. Among others, it's suggested as an alternative to fix code broken under strict aliasing here: https://gcc.gnu.org/bugs/#nonbugs https://gcc.gnu.org/bugs/#nonbugs. It's also relatively safe to assume that GCC will continue to be able to compile the Linux kernel for the indefinite future, since it would be very high profile, cause a ton of drama, and result in many people to moving away from GCC (including contributors). It seems very unlikely to be a smart decision. (That's not to say lower profile projects than the linux kernel should rely on this. Using memcpy/memmove is just as fast and that much more difficult).
bjourne 8y ago
The difference is that the code you wrote actually is dumb, but relying on union aliasing is not. :) A behavior doesn't need to be defined by the spec as long as it is defined by the implementation (gcc) you are targeting.
- cjensen 8y ago
  The code I wrote was dumb... and yet Stroustroup repeatedly made a variant of the mistake in the "C++ Programming Language." Turns out that the use of operator<< in iostreams is problematic.

waynecochran 8y ago

It's gcc defined behavior. Not the BS (his words) C standard behavior.

berti 8y ago

Did you actually read what he wrote? He agrees that's what the standard says, thus the standard is not workable in reality, so he goes with GCC's (defined in documentation) implementation. It doesn't "just happen to work" in GCC, it deliberately works, and GCC is the only compiler the core kernel devs care about (see ASM goto).

cjensen 8y ago
Sure. And that's a terrible reason. First, he's binding Linux to gcc forever. I've made that mistake and let me tell you, it's a mistake with surprisingly few benefits. A couple of asms and gccisms? Easily replaced. Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic. Third, "the standard is not workable in reality" is simply wrong. I work on low-level systems. I somehow manage to work with devices and networks on a day-to-day basis without relying on this. Ultimately it comes down to this: Linus put his faith in something which was explicitly removed from C 30 years ago. The writing has been on the wall for about 10 years now[1]: Good optimizers are going to do away with this mis-feature. Time to start adapting to reality. [1] http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/ http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al...
- yoklov 8y ago
  > Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic. Type punning through a union works on GCC without -fno-strict-aliasing, and is documented in multiple places. Among others, it's suggested as an alternative to fix code broken under strict aliasing here: https://gcc.gnu.org/bugs/#nonbugs https://gcc.gnu.org/bugs/#nonbugs. It's also relatively safe to assume that GCC will continue to be able to compile the Linux kernel for the indefinite future, since it would be very high profile, cause a ton of drama, and result in many people to moving away from GCC (including contributors). It seems very unlikely to be a smart decision. (That's not to say lower profile projects than the linux kernel should rely on this. Using memcpy/memmove is just as fast and that much more difficult).

bjourne 8y ago

The difference is that the code you wrote actually is dumb, but relying on union aliasing is not. :) A behavior doesn't need to be defined by the spec as long as it is defined by the implementation (gcc) you are targeting.

cjensen 8y ago
The code I wrote was dumb... and yet Stroustroup repeatedly made a variant of the mistake in the "C++ Programming Language." Turns out that the use of operator<< in iostreams is problematic.