[sslh] OS X 10.6 does not know memem

[Kai Ellinger]

Hello Yves,

this is the patch I found / mean. So it was Tor.
https://gist.github.com/amotl/1811671

And Tor implemented a memmem wrapper that way:

https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/compat.c
 545 /** Given <b>hlen</b> bytes at <b>haystack</b> and <b>nlen</b> bytes at
 546  * <b>needle</b>, return a pointer to the first occurrence of the needle
 547  * within the haystack, or NULL if there is no such occurrence.
 548  *
 549  * This function is <em>not</em> timing-safe.
 550  *
 551  * Requires that <b>nlen</b> be greater than zero.
 552  */
 553 const void *
 554 tor_memmem(const void *_haystack, size_t hlen,
 555            const void *_needle, size_t nlen)
 556 {
 557 #if defined(HAVE_MEMMEM) && (!defined(__GNUC__) || __GNUC__ >= 2)
 558   tor_assert(nlen);
 559   return memmem(_haystack, hlen, _needle, nlen);
 560 #else
 561   /* This isn't as fast as the GLIBC implementation, but it doesn't need to
 562    * be. */
 563   const char *p, *end;
 564   const char *haystack = (const char*)_haystack;
 565   const char *needle = (const char*)_needle;
 566   char first;
 567   tor_assert(nlen);
 568 
 569   p = haystack;
 570   end = haystack + hlen;
 571   first = *(const char*)needle;
 572   while ((p = memchr(p, first, end-p))) {
 573     if (p+nlen > end)
 574       return NULL;
 575     if (fast_memeq(p, needle, nlen))
 576       return p;
 577     ++p;
 578   }
 579   return NULL;
 580 #endif
 581 }

BR,
Kai

Am 31.03.2014 um 22:00 schrieb Kai Ellinger <kai2 at blicke.de>:

> Hello Yves,
> 
> Good question. After a first check it seems that there is no independent port of memmem for  OSX 10.6 because OSX 10.7++ supports it. 
> 
> When searching for the error it seems some BitTorrent program has som code to decide whether to use memmem or not. At the end a not 100% solution for that OS would be enough. 10.6 is not the freshest anyway. I will try to understand what the other project does if memmem is not availabe. I just saw the patch proposal which did not include the executed source code, only precompiler changes.   
> 
> /Kai Ellinger
> 
>> Am 30.03.2014 um 17:47 schrieb Yves Rutschle <yves at rutschle.net>:
>> 
>> Is it possible to link against glibc instead of the native
>> libc?
> 
> _______________________________________________
> sslh mailing list
> sslh at rutschle.net
> http://rutschle.net/cgi-bin/mailman/listinfo/sslh
>