Subject: Re: RFC: memmem(3)
To: None <tech-userlevel@netbsd.org>
From: None <wulf@ping.net.au>
List: tech-userlevel
Date: 03/04/2003 00:37:27
G'day,

After having received a number of responses I believe it is timely
for me to give account and reply to some of the comments received.

-- memmem(3) was not written to compete against specialized routines
   such as bm(3) and others. memmem(3) is lightweight with a very 
   small footprint see below

   -rw-r--r--  1 root  wheel    700 Mar  3 21:53 memmem.o

   There are numerous libraries that are designed to provide
   heavy-weight support for text/binary data searches, intended
   for application that are performance driven and where storage
   overheads are of no concern. 

-- Boye/Moore and many of the other algorithm require additional
   storage for various data structures such as skip tables etc.
   Wasting such commodities is a no-no in embedded applications.
   memmem(3) is your friend - lean and mean. 

-- memmem(3) complements the family of libc string functions
   defined in <string.h>. Whilst not being cited by any standard
   its merid is based on simplicity and robustness. Its easy to use
   and does not require pre-processing of data.

-- Unlike the Boyer/Moore and the other cited algorithms, memmem(3) has
   little overhead and may actually yield better performance under
   certain conditions.

-- Those who solely indulge in NetBSD kernel hacking wouldn't  have
   made friends with memmem(3) and may be forgiven for their ignorance
   and their questioning of its purpose. In real life, there are
   applications that make use of it and I had to deal with them.

Naturally, I believe that the addition of memmem(3) in libc would constitue a
useful addition to the family of string functions.


cheerio Berndt