Eric Blake <[EMAIL PROTECTED]> wrote: > I'm trying to convert m4 to transparently handle embedded NUL. In the > process, > I need to move from strstr to memmem (if m4 were fully i18n already, I would > instead be moving from mbsstr to the length-based analog of mbsstr that > tolerates embedded NUL - is there such a thing?)
Not that I know of. > Several issues with memmem: > > - It uses memcmp without depending on the memcmp module, making it needlessly > fail on some older platforms. But memcmp is currently licensed LGPL; is it > okay with everyone that this patch relicenses it as LGPLv2+? (Or are such > platforms so obsolete that we can delete the memcmp module?) > - It passed up on using optimizations built into memchr when needle_len is 1. > Is it okay with everyone that this patch relicenses memchr as LGPLv2+? Changing memchr and memcmp is fine with me. > - test-memmem.c was flat-out broken (calling memmem with 3 instead of 4 > arguments). The reason it was never compiled was the lack of a memmem-tests > module. > - There are platform-specific bugs in existing memmem implementations. > Cygwin, > for example, returns NULL instead of haystack for memmem(haystack,len,"",0). > How best do I document platform bugs in non-standardized functions? > - The implementation was naively quadratic in the worst-case complexity. I > lifted Bruno's KMP ideas in mbsstr to make it linear+delayed allocation. > glibc > still uses the naive implementation - should we file a bug with them to fix > it? Should we update memmem.m4 to reject known-quadratic implementations? It's worth a try. > Here's a patch for these issues; it breaks sync with glibc (and hence loses > the > K&R declaration). Tested on cygwin (where memmem is broken) and mingw (where > memmem is missing). Okay to apply? Sounds good to me. Thanks!
