I was wondering, does Intel C++ compiler have bounds checking available? I am working with tons of code evolving for ten years now, and in desperate need for debugging and refactoring. I need any help I can get.
Asked
Active
Viewed 2,055 times
3 Answers
4
Intel's compiler has several bounds checking options. E.g.
check-pointers, Qcheck-pointers Determines whether the compiler checks bounds for memory access through pointers.
Krazy Glew
- 7,210
- 2
- 49
- 62
-
Related new feature: https://software.intel.com/en-us/articles/intel-memory-protection-extensions-enabling-guide – Nemo Apr 04 '18 at 19:32
2
C arrays are fundamentally broken this way, you cannot reliably bounds-check them. Nor can the compiler. Intel's C++ compiler however certainly can compile the vector class. Turn on iterator debugging, use the at() accessor.
Hans Passant
- 922,412
- 146
- 1,693
- 2,536
-
It is incorrect to say that you cannot reliably bounds check C arrays. If you are willing to restrict yourselves to standards compliant portable C code, then it is undefined to access beyond the end of an array, so a compiler or runtime can signal errors. You must allow pointers to have values like array[-1] or array[size] (one element past either end), but you can trap on dereferencing them. – Krazy Glew Jul 16 '17 at 16:19
-
Intel's C compiler Qcheck pointers does this. There is even hardware support, Intel MPX (Memory Protection eXtensions) that is supposed to make this run faster. (I say "supposed to" because Intel broke my original design for what became MPX, resulting in it often being slower than not using the MPX instructions. I can only hope that this will be fixed inthe future.) – Krazy Glew Jul 16 '17 at 16:22
-
The key to such pointer checking for C is that, whenever you take the address of an object, you associate bounds with that address. Intel's pointer checking compiler and MPX store that bounds in special registers inside the CPU and in a special "non-adjacent" data structure essentially accessed by a hash lookup of the pointer address in memory. I called this non-adjacent fat-pointers.) It's completely compatible with portable C code, running all validation test suites. It even found bugs in the SPEC benchmarks that we were not aware of. – Krazy Glew Jul 16 '17 at 16:25
-
Yes, there is some C code that breaks the rules. Intel's pointer checking compiler and MPX often flag errors in such code, that can be easily fixed. Moreover, a surprisingly large amount of such code runs anyway, because it does not actually cause buffer overflows. – Krazy Glew Jul 16 '17 at 16:28
-
I think that it is fairly accurate to say that the bounds checking problem in C and C++ can be solved, via something like the Intel pointer checking compiler, if you can accept the performance costs. And that a better version of Intel MPX hardware support could make those costs much less expensive. – Krazy Glew Jul 16 '17 at 16:30
-
TEMPORAL memory problems, on the other hand, are harder. E.g. detecting use-after-free or double free bugs. I did not want to handle them in version 1.0 of what became Intel MPX because, as far as I can tell, all solutions to temporal memory problems eventually require the moral equivalent of garbage collection. To solve that requires a run-time. Hardware support might make it cheaper, e.g. to require version numbers of object and pointer to match (i.e. a transparent version of the versioned_ptr
which I submitted to Boost, but eventually version number wrap must be handled. – Krazy Glew Jul 16 '17 at 16:36
