kern/78256: strstr could be more robust
danallen46 at airwired.net
Sun Jul 3 18:50:41 GMT 2005
On Mar 9, 2005, at 2:18 PM, Bruce Evans wrote:
> On Wed, 9 Mar 2005, Dan Allen wrote:
>> On Mar 9, 2005, at 7:18 AM, Gleb Smirnoff wrote:
>>> Not a bug, sorry. See also bin/52691.
>> Why are you so reluctant to add one test to improve robustness?
>> Since it is not specified one way or the other in the standard, it
>> will not break compatibility with the standard. So it is not a
>> bug technically - you still could with a single line of C code
>> improve the robustness of the system. Not doing so seems
> Adding the test would unimprove robustness (except on systems that
> trap on null pointers -- then a test, followed by a call to abort() or
> signal(), would be needed to give the same behaviour as a null pointer
> trap). Aborting a program immediately when undefined behaviour in it
> is detected improves robustness by limiting the undefined behaviour to
> just halting the program and possibly generating a core dump, and by
> making the bug obvious and easy to debug so that it gets fixed.
My use of strstr() is quite a bit different than if I had an off-by-
one error, or if I overflowed a buffer, or some other definitely bad
practice. My use of strstr() is perfectly legitimate, but it falls
into the area of an undefined case in the C standard. Searching for
something in nothing should return nothing, not crash, i.e., strstr
(NULL,"a string") should return NULL. Plauger agrees with me and he
is the best expert on the C standard.
I guess my belief is this: it is never proper to crash. It is better
for a function to return some error code that at least informs the
caller that an illegal argument was given than it is to just
immediately die. You believe it is better to just crash the system
immediately rather than return an error code.
So why do even support errno then? It is a method of returning error
codes. By your reasoning programmers should find their errors by
letting improper function calls cause a segment violation or bus
fault... a very poor method indeed.
Thanks for listening. I still like FreeBSD but am somewhat dismayed
at this philosophy...
More information about the freebsd-bugs