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: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Tue, 8 Oct 2013 12:27:38 -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>
On Tue, Oct 08, 2013 at 12:01:39PM -0400, Carlos O'Donell wrote:
> On 10/07/2013 10:19 AM, Rich Felker wrote:
> > If you're going to check for NULL pointer arguments where you have
> > not entered into a contract to accept and interpret them, do it
> > with an assert, not a conditional error return. This way the bugs
> > in the caller will be immediately detected and can be fixed, and
> > it makes it easy to disable the overhead in production builds. I
> > question the value of the assert except as documentation however;
> > a segfault from dereferencing the NULL pointer is just as
> > effective for debugging.
>
> Should we have an assert there then to document the contract and provide
> a more meaningful error message like a backtrace?
There are probably hundreds of places all over glibc where this same
issue applies. I don't think documenting them all at the source level
via assertions is a productive use of developer time, source code
size, binary size, or changelog and git log clutter. C programmers
should not be treating the passing of NULL where a string is expected
as a diagnosable error but as what it is: undefined behavior. Usually,
a crash will naturally result and be easy enough to debug.
Rich