Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

[Florian Weimer <fweimer@redhat.com>]

* 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