Alan Barrett wrote:
> To: [email protected], [email protected]
> 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,
