This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #13724] Do not segfault in pthread_setname_np (x, NULL)
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Rich Felker <dalias at aerifal dot cx>, OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Tue, 08 Oct 2013 15:09:33 -0400
- 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>
On 10/08/2013 12:45 PM, Andreas Schwab wrote:
> "Carlos O'Donell" <carlos@redhat.com> 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:
https://sourceware.org/glibc/wiki/Style_and_Conventions#Assertions
~~~
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.
~~~
Cheers,
Carlos.