3 ms·

Another approach would be a standard library of arithmetic routines that signal overflow. If people used them while parsing binary inputs that would prevent a

• rseacord 7y ago
  Take a look at N2466 2020/02/09 Svoboda, Towards Integer Safety which has some support in the committee: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf (signal is a strong word... maybe indicate?)
• asveikau 7y ago
  Microsoft in particular has a simple approach to this with things like DWordMult(). if (FAILED(DWordMult(a, b, &product))) { // handle error }
  • stephencanon 7y ago
    Clang and GCC's approach for these operations is even nicer FWIW (__builtin_[add/sub/mul]_overflow(a, b, &c)), which allow arbitrary heterogenous integer types for a, b, and c and do the right thing. I know there's recently been some movement towards standardizing something in this direction, but I don't know what the status of that work is. Probably one of the folks doing the AUA can update.
    • AaronBallman 7y ago
      We've been discussing a paper on this (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf) at recent meetings and it's been fairly well-received each time, but not adopted for C2x as of yet.
      • stephencanon 7y ago
        It feels like it would be a real shame to standardize something that gives up the power of the Clang/GCC heterogeneous checked operations. We added them in Clang precisely because the original homogeneous operations (__builtin_smull_overflow, etc) led to very substantial correctness bugs when users had to pick a single common type for the operation and add conversions. Standardizing homogeneous operations would be worse than not addressing the problem at all, IMO. There's a better solution, and it's already implemented in two compilers, so why wouldn't we use it? The generic heterogeneous operations also avoid the identifier blowup. The only real argument against them that I see is that they are not easily implementable in C itself, but that's nothing new for the standard library (and should be a non-goal, in my not-a-committee-member opinion). Obviously, I'm not privy to the committee discussions around this, so there may be good reasons for the choice, but it worries me a lot to see that document.
        • wklieber 7y ago
          >the original homogeneous operations (__builtin_smull_overflow, etc) led to very substantial correctness bugs when users had to pick a single common type for the operation and add conversions. Hi Stephen, thank you for bringing this to our attention. David Svoboda and I are now working to revise the proposal to add a supplemental proposal to support operations on heterogeneous types. We are leaning toward proposing a three-argument syntax, where the 3rd argument specifies the return type, like: ckd_add(a, b, T) where a and b are integer values and T is an integer type, in addition to the two-argument form ckd_add(a, b) (Or maybe the two-argument and three-argument forms should have different names, to make it easier to implement.)
          • stephencanon 7y ago
            Glad to hear it, looking forward to seeing what you come up with! The question becomes, once you have the heterogeneous operations, is there any reason to keep the others around (my experience is that they simply become a distraction / attractive nuisance, and we're better off without them, but there may be use cases I haven't thought of that justify their inclusion).
• colanderman 7y ago
  You can enable this in GCC on a compilation unit basis with `-fsanitize=signed-integer-overflow`. In combination with `-fsanitize-undefined-trap-on-error`, the checks are quite cheap (on x86, usually just a `jo` to a `ud2` instruction). (Note that while `-ftrapv` would seem equivalent, I've found it to be less reliable, particularly with compile-time checking.)
  • corndoge 7y ago
    And clang!