On 30.07.2017 16:51, Taylor R Campbell wrote: >> Date: Sun, 30 Jul 2017 16:24:07 +0200 >> From: Kamil Rytarowski <n54%gmx.com@localhost> >> >> I would allow size to be 0, like with the original reallocarr(3). It >> might be less pretty, but more compatible with the original model and >> less vulnerable to accidental panics for no good reason. > > Hard to imagine a legitimate use case for size = 0. Almost always, > the parameter will be sizeof(struct foo), or some kind of blocksize > which necessarily has to be nonzero. > > I started writing some example code, and I'm not too keen on having to > write kmem_reallocarr for initial allocation and final freeing, so if > we adopted this, I'd like to have > > int kmem_allocarr(void *ptrp, size_t size, size_t count, km_flag_t flags); > int kmem_reallocarr(void *ptrp, size_t size, size_t ocnt, size_t ncnt, > km_flag_t flags); > void kmem_freearr(void *ptrp, size_t size, size_t count); > > ...at which point it's actually not clear to me that we have much of a > use for kmem_reallocarr. Maybe we do -- I haven't surveyed many > users. > > This still doesn't address the question of whether or how we should > express bounds on the allowed sizes of the arrays. > I see, perhaps it's legitimate to avoid realloc due to fragmentation. Without this reallocarr has little point.
Attachment:
signature.asc
Description: OpenPGP digital signature