tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: reallocarr(3)

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


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

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

+ 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).

Home | Main Index | Thread Index | Old Index