This is the mail archive of the libc-alpha@sourceware.org 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] |
On 10/08/13 12:48, Carlos O'Donell wrote:
Another approach would be similar to what we're doing with memstomp. ie, build a set of wrappers which check for these argument goofs and allow users to dl-preload DSOs with the wrappers.On 10/08/2013 12:27 PM, Rich Felker wrote: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.Doesn't this violate the previous reason for wanting to avoid the NULL check? If we don't assert the NULL may get stored in a structure or array and eventually find it's way to code that dereferences it much much later and cause a crash that is not near the place at which the application entered into undefined behaviour. It seems incredibly useful to enable the asserts and trigger these violations as early as possible. If you don't care you can disable the asserts?
When I first proposed the idea for these sanity checking dl-preload libraries for Fedora I envisioned that we could go beyond just checking for overlapping memory areas in the mem* and str* functions. There could be a set of pthread wrapper functions that check for whatever invariants we can in the pthread* functions without a huge performance hit.
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |