Eric Blake wrote:
> Hmm. I'm now starting to wonder whether I should create a new module
> strstr-simple, which fixes broken strstr (in the presence of broken
> memchr) but without worrying about quadratic vs. linear (similar to
> strcasestr-simple which only worries about providing strcasestr on
> platforms that lack it, compared to strcasestr which worries about speed).
Would make sense, for consistency with 'strcasestr'.
> Also, since we know strstr and strcasestr are broken on various glibc
> versions, it seems like we should add dependencies of client modules
> (argz.c, gen-uni-tables.c, mountlist.c all use strstr; I didn't see any
> use of strcasestr); but should this be on the new strstr-simple module, or
> the fullblown strstr module?.
For argz.c, it should be strstr, since the arguments can be arbitrarily
long.
For gen-uni-tables.c and mountlist.c, it should be strstr-simple, since
the second argument is always known to be of small length.
> I still think it would be interesting to get my hands on one of the
> machines like in the Debian report, so that I could also test whether
> printf("%.*s",...) segfaults on an appropriately fenced string.
It won't segfault: The use of memchr in vasnprintf.c is guarded by
#if !USE_SNPRINTF && !HAVE_STRNLEN
and on glibc platforms, both USE_SNPRINTF and HAVE_STRNLEN are defined to 1.
Bruno
