kern/78256: strstr could be more robust

[Dan Allen]

The following reply was made to PR kern/78256; it has been noted by GNATS.

From: Dan Allen <danallen46 at airwired.net>
To: Bruce Evans <bde at zeta.org.au>
Cc: Gleb Smirnoff <glebius at FreeBSD.org>, freebsd-bugs at FreeBSD.org
Subject: Re: kern/78256: strstr could be more robust
Date: Sun, 3 Jul 2005 12:50:38 -0600

 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