kern/78256: strstr could be more robust

[Dan Allen]

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  
>> shortsighted.
>>
>
> Adding the test would unimprove robustness (except on systems that  
> don't
> 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.

<SOAPBOX>
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.
</SOAPBOX>

Thanks for listening.  I still like FreeBSD but am somewhat dismayed  
at this philosophy...

Dan