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

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

Alan Barrett wrote:
> To: tech-userlevel%netbsd.org@localhost, tech-kern%netbsd.org@localhost
> Subject: Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD
>
> On Sat, 29 Nov 2014, Kamil Rytarowski wrote:
> > 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]
> 
> OK, so you have told us the names of the proposed functions.  But what
> are their semantics, and why would they be useful?
> 

The purpose was to make a library for arithmetic operations with checking for overflow
(it doesn't matter whether undefined behavior or not). The first consumers are malloc(3) and realloc(3).
Grepping our sources for malloc and realloc shows that that there is often multiplication passed as the size parameter, and it could be replaced with reallocarray(3) that checks for overflow.

I've failed to write them in C99 without compiler extensions... The closest example is libo (entirely wrote with extensions), with usage:

if (overflow_mul(&c, a, b))
    printf("overflow!\n");

For more details see: https://github.com/xiw/libo
and an article of the author: http://kqueue.org/blog/2012/03/16/fast-integer-overflow-detection/

It would way easier to do it with C11 _Generic...

My initial intention was to make it available for the kernel....
I've decided to not go for dozen of variants of overflow_XmulY.... as it wouldn't be obvious how to handle functions that take typedefed parameters (size_t, ssize_t etc). A user would be sure whether size_t is ulong or ulonglong... etc. Making it the other way than type agnostic won't help.

> > Last but not least please stop enforcing 
> > programmers' fancy to produce this kind of art: 
> > https://github.com/ivmai/bdwgc/commit/83231d0ab5ed60015797c3d1ad9056295ac3b2bb 
> > :-)
> 
> Please don't assume that people reading your email messages have
> convenient internet access.  It's fine to give URLs thatrexpand on what
> you have said, but if you give the URL without any explanation then I
> have no idea what you are talking about.
> 
> --apb (Alan Barrett)
> 

OK!

Back to the topic, I've posted a problem-report with the patches that merge reallocarray(3) with out sources.

http://mail-index.netbsd.org/netbsd-bugs/2014/12/19/msg039485.html

Tested and verified to work! Please review and apply!

As a bonus I've extended our malloc(3) man-page :) partly with information taken from OpenBSD's malloc(3).

Thank you very much,