Wireshark-commits: [Wireshark-commits] rev 53556: /trunk/ /trunk/: CMakeLists.txt configure.ac
Date: Sun, 24 Nov 2013 22:51:45 GMT
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53556

User: guy
Date: 2013/11/24 10:51 PM

Log:
 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).

Directory: /trunk/
  Changes    Path              Action
  +0 -1      CMakeLists.txt    Modified
  +0 -1      configure.ac      Modified