POSIX: re-enable strict aliasing

POSIX: re-enable strict aliasing

BUG=32204

[Paweł Hajdan Jr., 2013-08-15 01:38:34]

WDYT? There are some trybot issues to be figured out (just on Android I think),
but I was just thinking I'd ask whether this makes sense, and if so finish the
details.

[Mark Mentovai, 2013-08-15 14:29:07]

I don’t have a very strong opinion here. On one hand, it does let the compiler
do a better job, but I’m not sure we can rely on compiler warnings to flush out
all of the trouble spots. Perhaps you should float this to chromium-dev.

https://codereview.chromium.org/12091004/diff/36001/chrome/browser/crash_hand...
File chrome/browser/crash_handler_host_linux.cc (right):

https://codereview.chromium.org/12091004/diff/36001/chrome/browser/crash_hand...
chrome/browser/crash_handler_host_linux.cc:238: int fds[2] = { -1, -1 };
Don’t initialize, the memcpy follows immediately.

[Paweł Hajdan Jr., 2013-08-19 20:09:36]

The chromium-dev thread is
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/dUebWSEpAR8/xhsis...

I'm rather leaning towards not enabling strict aliasing (can consider enabling
the warnings if possible, in which case parts of this CL could still be used).

WDYT?

https://codereview.chromium.org/12091004/diff/36001/chrome/browser/crash_hand...
File chrome/browser/crash_handler_host_linux.cc (right):

https://codereview.chromium.org/12091004/diff/36001/chrome/browser/crash_hand...
chrome/browser/crash_handler_host_linux.cc:238: int fds[2] = { -1, -1 };
On 2013/08/15 14:29:07, Mark Mentovai wrote:
> Don’t initialize, the memcpy follows immediately.

Done.

[Mark Mentovai, 2013-08-19 20:24:39]

I’m not sure about Clang, but I think that with GCC, you don’t get the warnings
(even with -Wstrict-aliasing) unless -fstrict-aliasing is on.

If you’d like to proceed without enabling strict aliasing and want to recycle
this CL, you can edit its description and drop the .gyp changes that enable
-fstrict-aliasing.

Since you’re messing with the CMSG code in some of these cases such as
quic_socket_utils.cc, I’d suggest adding validation that the data length is
either equal to or greater than the expected length for the memcpy, as a DCHECK
or something along those lines. This could be similar to the checks in
crash_handler_host_linux.cc’s SCM_RIGHTS case checking that the data is
properly-sized. Since I’m looking at that code, do you want to do something
about the SCM_CREDENTIALS case too?