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 14:18:41 +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 8ECEF3D95E
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8ECEF3D95E
- References: <firstname.lastname@example.org>
On 05/16/2017 07:22 PM, DJ Delorie wrote:
> Florian Weimer <email@example.com> writes:
>> Oh. Well. I don't think I want to paper over *that*. A crash in
>> strlen seems to be just fine, rather than ignoring the issue and perhaps
>> returning grossly misleading data.
> I think you misunderstand - I *intentionally* put bad data in the test
> data to make sure the code handles it without crashing, and passes it
> along accurately, and that the testsuite can detect and validate it.
> A crash in strlen() means I can't use your code, or have to wrap it in
> my own checks because I can't trust it.
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.