Re: reallocarr(3)

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

Joerg Sonnenberger wrote:

> Hi all,
> as discussed in the recent strtonum thread, I believe that reallocarray
> is wrong in the way it makes error handling more complicated to get
> right. Attached is an alternative, including modifications for regcomp.c
> for an IMO better interface. There is one issue with reallocarr(3) and
> that's related to the C type system. Sadly, void ** and foo ** are not
> implicit cast compatible, that's why the prototype takes a void *
> argument.
> 
> Joerg
> 

Hello,

Christos first of all thank you for your initial inclusion!

But back to Joerg, there is suggested a new interface,
moving reallocarray(3) to the _OPENBSD_SOURCE name-space.

The main properties of reallocarray(3):
+ safe realloc(3) with overflow detection,
+ safe malloc(3) with overflow detection without initialization overhead of calloc(3)
an article http://lteo.net/blog/2014/10/28/reallocarray-in-openbsd-integer-overflow-detection-for-free/

~ malloc, realloc, calloc usage idioms (are they difficult here?)

reallocarr(3):
+ distinguish ENOMEM and EOVERFLOW
+ tries to preserve global errno

~ hacky way to manage foo** pointers, is it portable? is it safe?
~ no malloc(3) replacement without initialization overhead
~ not realloc(3) replacement, as passing NULL won't work
~ change malloc, realloc, calloc usage idioms - error passed through return value, delta in our programs will be larger

My proposition is to just distinguish EOVERFLOW and ENOMEM in reallocarray(3).