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: 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 12:13:25 +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> <1381266054 dot 18547 dot 1106 dot camel at triegel dot csb> <52547BCD dot 1030200 at redhat dot com>
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?