Re: [PATCH] Allocation buffers for NSS result construction

[DJ Delorie <dj at redhat dot com>]

Florian Weimer <fweimer@redhat.com> writes:
> I don't quite understand what you are after.  I think if the code has to
> deal with bad data, explicit checks are better than relying on fringe
> behavior of library functions (printf and "(null)" is another example).
>
> Please post example code, so that I can better understand your requirement.

https://www.sourceware.org/ml/libc-alpha/2017-05/msg00074.html

The data I'm passing from the nss_test helpers may have NULL where a
"char *" string is expected.  If the NSS core calls strlen() on it, it
will crash.  When I'm building the buffer, I can't just call strlen() or
it will crash.  I'm testing to make sure it doesn't crash, and that the
NULL is passed along to the caller.

So either your strlen() (or any other function taking a string) needs to
handle NULL in a defined non-crashing way, or any code using it still
needs to do its own handling.  It would be better if handling NULL were
defined in a graceful way by your API to avoid replicating the NULL case
handling at all callers.

For example, if I want to add a NULL string to an array of strings, your
code needs to safely put a NULL pointer in the list (somehow) without
allocating space for it.  This is separate from a zero-length string,
where a valid pointer is stored and spac for a NUL byte is allocated.

If I can't put a NULL string in an array of strings at all, your code
can't be used for my case.