Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD

["Kamil Rytarowski" <n54%gmx.com@localhost>]

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?