Re: memmem.c improvement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 1 Dec 2007, Christian Thaeter wrote:

I am fully aware that this is not the best possible search algorithm.
It is considerably better than the actual one for 'common' data.

And not considerably worse in the worst case I could think of. (Which was my point, not that it was slow or sucked in some other way.)

Having a string with few symbols or other corner cases needs an algorithm better suited for that task.

Yes, if it's actually worth anyone's time making strstr() fast in the case where the haystack has length three and the needle length two.

Amusingly enough, I haven't ever seen strstr() used to do any nontrivial string matching in any free software I've bothered to grep.

But well, this was just reaching a low hanging fruit.

Suitably hacked, your code looks clearly correct. But there are valid reasons not to mess with the strstr() in libc (fewer for memmem()); chief among them is that *if* there is an undetected bug in the code, *then* lots of stuff can break.

For me it suffices and I won't put more efforts into improving or lobbying it, its just not worth it.

Clearly, the tone of my email did not help convey my message. (Perhaps I should just stop trying to write words of encouragement altogether --- it never goes according to plan and always seems to end in disaster.) I do commend you for submitting improvements (and this is clearly an improvement); I was merely trying to point out that it will likely be an uphill battle, and that certain things are either wrong or can be done better than you have done. Do go on, please! (And I'm sorry if my previous email caused you particular dismay.)

Tor Myklebust
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux