[PATCH][BZ #13724] Do not segfault in pthread_setname_np (x, NULL)
Carlos O'Donell
carlos@redhat.com
Wed Oct 9 14:56:00 GMT 2013
On 10/09/2013 05:13 AM, Torvald Riegel wrote:
> On Tue, 2013-10-08 at 17:40 -0400, Carlos O'Donell wrote:
>> On 10/08/2013 05:00 PM, Torvald Riegel wrote:
>>>> 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?
>>
>> What would you say?
>
> I think what you wrote would be fine currently. The precondition check
> should probably get a different name, even if it is similar to assert();
> candidate names might be "check_contract()" or "check_precondition()" or
> something like that. But we don't have these yet, so we also can't put
> it in the style guide :)
>
> My main point was that we probably should have different terms for both
> assertions and precondition checks for caller input and, in general, how
> callers try to use the library.
>
> Once we had something like check_precondition, I suppose we could remove
> the last of the paragraphs you wrote (the one about recorded input)
> altogether, and rather suggest to add precondition checks.
>
> Does this direction sound sensible?
It does.
Cheers,
Carlos.
More information about the Libc-alpha
mailing list