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