This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][BZ #13724] Do not segfault in pthread_setname_np (x, NULL)

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:
> >>
> >> ~~~
> >> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]