Paul Eggert <[EMAIL PROTECTED]> wrote: > I ran into a problem building CVS coreutils on Debian stable, since > coreutils does not use some of the string.h-related modules, but > Debian string.h #defines some of the symbols that string.h therefore > attempts to #define to foo_is_unportable, and the #defines collide. > > I worked around my particular problem by installing the patch proposed > below. But I see further problems in this area. For example, > mountlist uses strstr in a system-dependent way where the ASCII-only > system strstr is just fine. A program that uses mountlist shouldn't > need to use the gnulib strstr if it doesn't want to. But with gnulib > string_.h as it is, it will have to use gnulib strstr.
Thanks! You beat me to it. > How about if we remove the > strstr_is_unportable__use_gnulib_module_strcasestr_for_portability > symbols? They do solve a problem, but I'm not sure it's worth > the porting hassle of continuing to support them. > > Maybe there's a better way to address the same problem? I hope so. I like the safety net. How about a c-strstr module, analogous to c-strtod? i.e., strstr as if it were operating in the C locale. It'd end up using vendor-supplied strstr in most cases.
