A C++ or C compiler that generates code to check signed-integer overflow by default, and do anything at all (call a handler, throw an exception, dump core, close your network connection, erase your disk) is completely standard-conforming. Gcc and Clang could have such a feature in no time, if any of you-all cared to code it. Firefox and Chrome could use it immediately after. Probably the speed would not be noticeably affected.
But of course then the ground would shift to plug-ins and libraries. Most of those could be compiled using the same compiler option, for the same benefit, just as we-all already use our compilers' built-in stack-smashing protection (don't we?).
Likewise, any C or C++ compiler may do anything it likes with out-of-bound accesses to native array types. Code it, and anyone using Gcc or Clang can use it for free. Again, the resulting programs would still be miles faster than your favorite wanklage.
Do you run valgrind on code you are responsible for? Why not? Even in production use, C or C++ code running under valgrind is still faster than in most "advanced", "high-level" languages. Valgrind can also respond to violations it detects in programmed ways, independent of compiler or library.
The fault, dear brute, is not in our languages, but in ourselves, that we code insecurely.
Posted May 25, 2012 4:03 UTC (Fri) by foom (subscriber, #14868)
[Link]
> A C++ or C compiler that generates code to check signed-integer overflow by default, and do anything at all [...] is completely standard-conforming
Nice trick you pulled there, slipped "signed" in! Yes, that's true about signed overflow, but *NOT* unsigned overflow. Which makes the whole safety thing rather half-baked...
> Gcc and Clang could have such a feature in no time
In fact, that option already exists in GCC:
-ftrapv This option generates traps for signed overflow on addition, subtraction, multiplication operations.
Except, it doesn't work; it's been totally broken for over 5 years and nobody has stepped up to fix it yet.
Are they using the right technology?
Posted May 28, 2012 6:52 UTC (Mon) by ncm (subscriber, #165)
[Link]
Unsigned ints don't overflow. They implement well-defined modular arithmetic. No operations on unsigned int yield undefined results.
If anybody actually had any use for range-checked C, that mode in Gcc would work. Likewise, array bounds checking. The reason that people don't have any use for them is that they would fail to catch the overwhelming majority of overflow and overindexing bugs. A program that fails to keep a short int less than 32768 is a program that also fails to keep it below 10000. A program that overindexes its built-in arrays also overindexes variable-sized storage.
Are they using the right technology?
Posted May 28, 2012 13:25 UTC (Mon) by nix (subscriber, #2304)
[Link]
Unsigned ints don't overflow. They implement well-defined modular arithmetic. No operations on unsigned int yield undefined results.
... which, if unexpected, can be and often is a security hole. You haven't solved anything.