Re: rawmemchr

[Jeff Johnston <jjohnstn at redhat dot com>]

Christopher Faylor wrote:
> On Wed, May 21, 2008 at 10:33:05PM +0000, Eric Blake wrote:
>   
> > Eric Blake <ebb9 <at> byu.net> writes:
> >
> >     
> > > Here's my test program:
> > >
> > >       int *ptr = (int *) str;
> > >       while (!DETECTNULL (*ptr) && !DETECTCHAR (*ptr, mask))
> > >         ptr++;
> > >       /* Found the end of string or word containing c.  */
> > >       str = (const char *) str;
> > >       
> > FYI.  That was supposed to be
> > str = (const char *) ptr;
> >
> > That one-character flaw in my test app C code resulted in searching the string 
> > twice (once fast and discarding the progress, then again bytewise).  With the 
> > test app fixed, I get these even more impressive numbers to demonstrate the 
> > benefits of my optimization:
> >     
>
> I really don't want to be a wet blanket here but I'm worried about
> changing something as fundamental as strchr based on one simple test
> program and the assurances of a programmer that everything is fine.
>
> It really seems to me that there should be proven optimized versions of
> these functions floating around which don't rely on more tweaking in
> May of 2008.
>
> I know that Eric is an exceptional programmer but I hope that more
> people will be doing a sanity check on this code.  This is not a
> function that can have bugs.
>
> cgf
>   
Note that the original assembler was written by myself in 1998.  There 
is no doubt in my mind that someone might do find a way to do it better 
and I welcome Eric's current efforts.

With regards to the best that is out there, remember that licensing is 
key.  Can't be proprietary, can't have an advertising clause,  and can't 
be GPL/LGPL unless it is put into libc/sys/linux.

In retrospect I should not have approved this so easily without having 
Eric verify what testing he had performed, however, it has been my 
experience that he is very thorough.  FWIW: my own rudimentary testing 
proved successful and together with Eric's assurance of running other 
testsuites, this warrants trying it out it my books.  This means it will 
get run through Cygwin  testing, RTEMS testing, etc..  If problems are 
discovered, the code will either be fixed or replaced with the previous 
version.  This is nothing new in the history of newlib.

I personally believe that any unforeseen error in this strchr code won't 
hide for long with the amount of code that uses it.  I wouldn't feel the 
same confidence about a malloc change, for example. 

I hope you are not still concerned.

-- Jeff J.