[PATCH][BZ #13724] Do not segfault in pthread_setname_np (x, NULL)
Torvald Riegel
triegel@redhat.com
Tue Oct 8 21:01:00 GMT 2013
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" <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.
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?
More information about the Libc-alpha
mailing list