* Paul Eggert: > What problems do you see with the interfaces, and are there efforts to > come up with a better API? The need is there in GNU apps, each of > which tends to roll its own code here.
dynarray has an aliasing violation in its implementation. The embedded pointer should be void * (not DYNARRAY_ELEMENT *), with casts added in the generated code, so that the out-of-line code can use the correct types. Defining the element free function has a trap for the unwary programmer: it's easy to miss the required pointer indirection. I don't know a good fix for that. I view dynarray as a stop-gap until we can use a C++ template inside glibc. We won't be able to use std::vector because of gaps in memory allocation failure handling, but application code interested in basic type-generic data structures should really use libstdc++ and not preprocessor hacks like dynarray. With such wide use of xmalloc & friends, the memory allocation issue would impact few applications. The scratch buffer interface is mainly intended as a helper for calling NSS functions because of their highly problematic buffer interface: it's not just that the caller allocates, the callee does not provide any size hint at all if the provided buffer is not large enough. So the only thing you can do is keep retrying with larger and larger buffers. No one should create interfaces like that. One could argue that scratch buffers are needed because the NSS interfaces exist today, but from a glibc perspective, I think we should provide replacements for the problematic NSS functions that are significantly easier to use, rather than relying on developers to put something together using scratch buffers. Maybe it's sufficient to make the original functions like getpwuid thread-safe, although such functions manipulating global state wouldn't be really library-safe. (You wouldn't want to call getpwuid in a library because it might clobber another getpwuid result still in use elsewhere, but that's an issue that is present with or without thread safety.) I added scratch_buffer_grow_preserve and scratch_buffer_set_array_size as an afterthought. Conceptually, they are unrelated to the NSS usage. They predate dynarrays. If dynarrays were easier to define, we should have switched over to them because they have implicit overflow checking for allocation sizes. Thanks, Florian
