Eric Blake <[EMAIL PROTECTED]> writes:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> 
>> > (remember, however, that the system memmem may be broken, as on
>> > cygwin).
>> 
>> Did the old check find that brokenness?  Has this brokenness been
>> discussed before, and was a m4 test to detect it produced?  I can't see
>> anything in memmem.m4 about it now.
>
> On cygwin 1.5.25-7 and earlier, memmem(ptr1,len,ptr2,0) returned NULL, not 
> ptr1.  This has since been fixed in cygwin CVS (but unreleased); with that 
> fix, 
> cygwin is now in the same boat as glibc 2.6.1 (working, but quadratic).  This 
> bug is detected by the following line in the run-time test, added when I 
> first 
> started touching memmem last month:
>
>     return !result || !memmem ("a", 1, 0, 0);]])],
>
> It's also documented in doc/functions/memmem.texi.

Ah, thanks.  This was not part of the old memmem.m4 checks.  Still, the
glibc documentation (which I regard as the memmem specification) doesn't
say what should be returned for empty needles.  My conclusion is that
empty needles should lead to undefined behaviour.  Thus, I wouldn't
directly consider not handling empty needles the same as the glibc
implementation as a brokenness that should be fixed by a gnulib module.

> For cross-compiling, I would just blindly replace memmem, even when targeting 
> glibc or other platform where the system memmem works, since that is easier 
> than dragging in a dependency on AC_CANONICAL_TARGET and adding a case 
> statement to distinguish known good systems.

Unfortunately, cross-compilation is in practice the typical scenario
where people care about size issues, so I would prefer to rely on
AC_CHECK_FUNC instead.  The typical free embedded platforms (uClibc,
glibc) have working memmem.  Further, AC_CANONICAL_TARGET is already
called when cross-compiling many gnulib applications (including gnutls),
so it is not an extra burden.

However, if it is easy to disable gnulib's copy of memmem by setting
some variable (and that were documented) your approach could work for
me...

/Simon


Reply via email to