Hello, + tech-kern@
I've revisited my idea of reallocarray(3). As it's an emerging standard (quickly merged with libbsd, developed in glibc) I won't discus the the facts :) and leave its benefits for interested readers to: http://www.lteo.net/blog/2014/10/28/reallocarray-in-openbsd-integer-overflow-detection-for-free/ Thank you, mainly Joerg for your constructive comments. I wish we assumed that due to pointer-aliasing traps (in the proposed alternative) reinventing new reallocarray-like function is not worth it. So back to the revisited idea. Current CLANG and GCC (5.0 [1]) support set of basic operators with checks for overflows, namely the '+', '-' and '*' operations. My proposition is to add a new header in src/sys/sys/overflow.h (/usr/include/sys/overflow.h) with the following content: operator_XaddY_overflow() operator_XsubY_overflow() operator_XmulY_overflow() X = optional s (signed) Y = optional l,ll, etc [* see comment] These functions will be static-inlined and in design fully MI, with discovery guards for features of GCC / CLANG (I presume that PCC still needs a patch contribution to add this feature), in case of missing in-compiler/platform support there will be a fall-back for pure (and simple) C implementation. Here is an interesting article of "We Need Hardware Traps for Integer Overflow" reflecting my ideas: http://blog.regehr.org/archives/1154 BTW. Actually it's possible to optimize overflow checks at i386/amd64 -- with a conditional jump at overflow a compiler will do it well, not sure for ARM right now. After wrapping up overflow.h (and merging with the current sources) I will propose reallocarray(3) that is compatible with OpenBSD, simpler to read and reusing our operator_mulY_overflow(). Last but not least please stop enforcing programmers' fancy to produce this kind of art: https://github.com/ivmai/bdwgc/commit/83231d0ab5ed60015797c3d1ad9056295ac3b2bb :-) What do you think? Best regards! [1] https://gcc.gnu.org/gcc-5/changes.html [*] I would like to see C99 type-generic macro here... but would it be allowed for portability reasons?
