[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

memmem

barcaroller

5/8/2011 2:54:00 AM

Does anyone know of a POSIX-equivalent for GNU's memmem(), which
searches for a sequence of bytes within a larger block of memory?
17 Answers

Bill Cunningham

5/8/2011 6:34:00 AM

0

barcaroller wrote:
> Does anyone know of a POSIX-equivalent for GNU's memmem(), which
> searches for a sequence of bytes within a larger block of memory?

I think you might want comp.unix.programmer

Bill

puppi

5/8/2011 7:11:00 AM

0

On May 7, 11:53 pm, barcaroller <barcarol...@music.net> wrote:
> Does anyone know of a POSIX-equivalent for GNU's memmem(), which
> searches for a sequence of bytes within a larger block of memory?

There is strstr(). It's defined by C89 and C99. The essential
difference between strstr() and memmem() is that strstr() assumes that
the "haystack" and the "needle" are null-byte ended, while in memmem()
the lengths are specified. Hence it's not quite an equivalence (but
unless you are reading raw binary data, it's close to that).

Bill Cunningham

5/8/2011 8:36:00 AM

0

puppi wrote:
> On May 7, 11:53 pm, barcaroller <barcarol...@music.net> wrote:

> There is strstr(). It's defined by C89 and C99. The essential
> difference between strstr() and memmem() is that strstr() assumes that
> the "haystack" and the "needle" are null-byte ended, while in memmem()
> the lengths are specified. Hence it's not quite an equivalence (but
> unless you are reading raw binary data, it's close to that).

Strstr() interesting choice I'll look at that. But he's asking about
POSIX and I wouldn't know how to answer myself.

Bill

James Kuyper

5/8/2011 1:33:00 PM

0

On 05/08/2011 03:11 AM, puppi wrote:
> On May 7, 11:53�pm, barcaroller <barcarol...@music.net> wrote:
>> Does anyone know of a POSIX-equivalent for GNU's memmem(), which
>> searches for a sequence of bytes within a larger block of memory?
>
> There is strstr(). It's defined by C89 and C99. The essential
> difference between strstr() and memmem() is that strstr() assumes that
> the "haystack" and the "needle" are null-byte ended, while in memmem()
> the lengths are specified. Hence it's not quite an equivalence (but
> unless you are reading raw binary data, it's close to that).

I strongly suspect that the OP is not working with null-terminated data.
--
James Kuyper

barcaroller

5/8/2011 2:47:00 PM

0

On 2011-05-08 03:11:17 -0400, puppi said:

> There is strstr(). It's defined by C89 and C99. The essential
> difference between strstr() and memmem() is that strstr() assumes that
> the "haystack" and the "needle" are null-byte ended, while in memmem()
> the lengths are specified. Hence it's not quite an equivalence (but
> unless you are reading raw binary data, it's close to that).

Thank your for your response. I am in fact dealing with raw binary
data. I am a bit suprised that strstr() is in C99, but no similar
function for binary data. I could roll my own, but I like GNU's
optimizations in memmem (making use of word boundaries etc).

barcaroller

5/8/2011 2:48:00 PM

0

On 2011-05-08 09:33:28 -0400, James Kuyper said:

> I strongly suspect that the OP is not working with null-terminated data.

You are right.

Angel

5/8/2011 3:56:00 PM

0

On 2011-05-08, barcaroller <barcaroller@gmail.com> wrote:
> On 2011-05-08 03:11:17 -0400, puppi said:
>
>> There is strstr(). It's defined by C89 and C99. The essential
>> difference between strstr() and memmem() is that strstr() assumes that
>> the "haystack" and the "needle" are null-byte ended, while in memmem()
>> the lengths are specified. Hence it's not quite an equivalence (but
>> unless you are reading raw binary data, it's close to that).
>
> Thank your for your response. I am in fact dealing with raw binary
> data. I am a bit suprised that strstr() is in C99, but no similar
> function for binary data. I could roll my own, but I like GNU's
> optimizations in memmem (making use of word boundaries etc).

You might want to be careful with that, memmem() is broken in several
versions of libc.


--
The perfected state of a spam server is a smoking crater.
- The Crater Corollary to Rule #4

barcaroller

5/8/2011 4:04:00 PM

0

On 2011-05-08 11:56:23 -0400, Angel said:

> You might want to be careful with that, memmem() is broken in several
> versions of libc.

I know that it was broken at some point in the past (in fact, it says
so in the manpage) but my understanding is that it has now been fixed.
If you know otherwise, please let me know (or point me to a source).

puppi

5/9/2011 11:48:00 AM

0

On May 8, 11:46 am, barcaroller <barcarol...@gmail.com> wrote:
> On 2011-05-08 03:11:17 -0400, puppi said:
>
> > There is strstr(). It's defined by C89 and C99. The essential
> > difference between strstr() and memmem() is that strstr() assumes that
> > the "haystack" and the "needle" are null-byte ended, while in memmem()
> > the lengths are specified. Hence it's not quite an equivalence (but
> > unless you are reading raw binary data, it's close to that).
>
> Thank your for your response.  I am in fact dealing with raw binary
> data.  I am a bit suprised that strstr() is in C99, but no similar
> function for binary data.  I could roll my own, but I like GNU's
> optimizations in memmem (making use of word boundaries etc).

If your project is open-source, you can always simply use glibc's
implementation in a "copy-paste" fashion. Just be sure to account for
the legal technicalities in doing that.

puppi

5/9/2011 11:59:00 AM

0

On May 8, 1:03 pm, barcaroller <barcarol...@music.net> wrote:
> On 2011-05-08 11:56:23 -0400, Angel said:
>
> > You might want to be careful with that, memmem() is broken in several
> > versions of libc.
>
> I know that it was broken at some point in the past (in fact, it says
> so in the manpage) but my understanding is that it has now been fixed.  
> If you know otherwise, please let me know (or point me to a source).

You could also bitwise AND with 0x01 each byte of the sequences to be
compared, filtering out the low bits (and preferably packing them 8 by
8 in a single byte), then bitwise OR the original sequences with 0x01,
put a sentinel 0x00 at the end and use 2 strstr()s (or 1 strstr() and
1 plain equality test for each possible match). Of course it wouldn't
be as efficient, but at least it's as alternative.