tech-userlevel archive

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

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



Joerg Sonnenberger wrote
> On Tue, Nov 25, 2014 at 01:42:54AM +0100, Kamil Rytarowski wrote:
> > Joerg Sonnenberger wrote
> > > As with strtonum, reallocarray has enough problems of its own. While it
> > > fixes the problem of overflows, it doesn't handle the problem of failing
> > > allocations gracefully. If you don't want to make that fatal or leak
> > > memory, you still have to use a separate variable. Another issue is that
> > > the API as it is doesn't properly deal with zero sized allocations. In
> > > short, this API is once again not nearly as useful as it could be and
> > > not something I want to see in libc...
> > > 
> > > Joerg
> > > 
> > 
> > Thank you for your feedback. These functions are meant to handle the overflow class of bugs, otherwise they are equivalent to the standard libc functions.
> > 
> > A graceful failing of allocations is domain specific (panic, exit, recover, sleep, ...).
> > 
> > Please propose an alternative.
> 
> bool reallocarray(void **newp, void *oldp, size_t nmemb, size_t size);
> 
> which returns true iff no error happened. If nmemb == 0 or size == 0,
> newp will either point to a unique allocation of a size 0 or NULL,
> depending on malloc flavor. newp is changed only on success, so a
> failing allocation will leave the backing store of oldp intact.
> 
> Joerg
> 

Thank you.

Well... I see your point, on the other hand your variant doesn't solve my initial (and real) issue of code derived from OpenBSD -- unmodified code sharing.

What do you think of this:
- import reallocarray(3) from OpenBSD for compatibility reasons
void *reallocarray(void *optr, size_t nmemb, size_t size);
- add a superclass function, namely reallocmem(3) (feel free to take a better name) of form
bool reallocmem(void **newp, void *oldp, size_t nmemb, size_t size);

reallocmem(3) will specialize itself:
- calling reallocarray(3) to take care of overflows,
- replacing newp with new pointer on success,
- explicit returning the status of memory reallocation.

A worth using modern compiler will take care of in-line optimization, so this is not a case anymore.

I presume no need for extra handling of user-space 0-sized memory allocations, as it's already defined as valid and implementation specific (dereferencing pointer dangerous, free(3) still encouraged on that pointer).

As a remind, after a general consensus I'm a volunteer for a patch. After merging strtonum(3) and realloc*(3) I suggest to make a general audit of the entire user-space code-base.

In the kernel we hardly ever (is there such place?) check for success of realloc... I was always wondering whether that is on purpose? But please begin from the user-space, start with the "theft of Egypt's gold" (reallocarray(3) from OpenBSD) and make it a building block of our code-base.


Home | Main Index | Thread Index | Old Index