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: Torvald Riegel <triegel 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 10:55:25 -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> <5254586D dot 50501 at redhat dot com> <1381266054 dot 18547 dot 1106 dot camel at triegel dot csb> <52547BCD dot 1030200 at redhat dot com> <1381310005 dot 18547 dot 1313 dot camel at triegel dot csb>
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.