According to
authorguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Sun, 24 Nov 2013 22:51:44 +0000 (22:51 +0000)
committerguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Sun, 24 Nov 2013 22:51:44 +0000 (22:51 +0000)
commit17a3e034d395f85b8a619afbd3413d838694bf77
tree42da63baa8c677cd6f874b00deba3593c4c05348
parent1d57a32c63ab2bc774ec21f259c7ff2205f1911c
According to

    http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Code-Gen-Options.html#Code-Gen-Options

-ftrapv "generates traps for signed overflow on addition, subtraction,
multiplication operations." and -fwrapv "instructs the compiler to
assume that signed arithmetic overflow of addition, subtraction and
multiplication wraps around using twos-complement representation."

Those seem mutually-exclusive to me, and we probably want wrapping, not
traps, as there's probably a fair bit of code out there that explicitly
or implicitly assumes wrapping.  (Actually, we really want to avoid
signed arithmetic for the cases that most matter, such as offsets and
lengths, but, unfortunately, we currently have API conventions that
allow negative values for lengths, either with -1 meaning "to the end"
or with negative values meaning "relative to the end".)  In addition,
there seem to be some bugs complaining that -ftrapv doesn't always cause
traps on signed integer overflow.

We seem to be seeing crashes in Lemon on the Solaris buildbot subsequent
to adding -ftrapv; I don't know whether that's an overflow being
detected, a bug in the compiler, or something unrelated, especially
given that we're using Sun C, not GCC, on the Solaris buildbot.
However, we'll try removing -ftrapv, to see if it fixes the problem; the
MIT CSAIL paper in question wasn't really recommending all the GCC
options it mentioned (which, as noted, wouldn't make sense, as -ftrapv
and -fwrapv appear to be mutually-exclusive).

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@53556 f5534014-38df-0310-8fa8-9805f1628bb7
CMakeLists.txt
configure.ac