This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Allocation buffers for NSS result construction
- From: Florian Weimer <fweimer at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 16 Jun 2017 23:19:54 +0200
- Subject: Re: [PATCH] Allocation buffers for NSS result construction
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E20D5B173
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E20D5B173
- References: <email@example.com>
On 06/16/2017 09:06 PM, DJ Delorie wrote:
> Florian Weimer <firstname.lastname@example.org> 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.
> 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
Do you mean the COPY_IF_ROOM macro?
I think you'll have to keep a NULL check in it because this use case is
quite obscure. I think most other NSS module implementations only copy
data into the output if they actually have any data, so the pointer is
already guaranteed to be not NULL when the data is copied.