This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #13724] Do not segfault in pthread_setname_np (x, NULL)
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, Rich Felker <dalias at aerifal dot cx>, OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Wed, 09 Oct 2013 00:00:54 +0300
- Subject: Re: [PATCH][BZ #13724] Do not segfault in pthread_setname_np (x, NULL)
- Authentication-results: sourceware.org; auth=none
- References: <20131003122009 dot GA8891 at domone dot podge> <524DCA52 dot 2030609 at redhat dot com> <20131007141928 dot GV20515 at brightrain dot aerifal dot cx> <52542C63 dot 10305 at redhat dot com> <mvmr4bvww2y dot fsf at hawking dot suse dot de> <5254586D dot 50501 at redhat dot com>
On Tue, 2013-10-08 at 15:09 -0400, Carlos O'Donell wrote:
> On 10/08/2013 12:45 PM, Andreas Schwab wrote:
> > "Carlos O'Donell" <firstname.lastname@example.org> writes:
> >> Should we have an assert there then to document the contract and provide
> >> a more meaningful error message like a backtrace?
> > Asseertions are for internal consistency checking, but this is an
> > external condition.
> So you're saying that the external conditions are governed solely
> by the API and that violating the API by passing a NULL value leads
> to undefined behaviour?
> In this case the error is immediate as strlen segfaults. I'm happy
> with that since it's easy to debug.
> However, I'm not happy that this consensus may lead to errors that
> are not near the point at which the application enters into
> undefined behaviour.
> I've documented what I understand is our practice for assert:
> Assertions are for internal consistency checking only.
> External conditions are governed by the API and if user
> code violates the API then the library behaviour is undefined.
> However, in scenarios where user input is recorded into
> internal structures for later use it is useful to assert
> in these cases to catch the first occurrence of the error.
Perhaps it's useful to distinguish between asserts (ie, the internal
consistency checks) and checks that test whether callers adhere to the
preconditions required by a function?