Bruno Haible <[EMAIL PROTECTED]> writes: > 1) If the maintainer has not included the strstr module but uses the > strstr function and activates _GL_CHECK_PORTABILITY: With your proposal > he will get a link error about function 'rpl_strstr', and will likely > report it as a bug in gnulib. With mine, he gets a link error about > 'strstr_in_unportable__use_gnulib_module_strstr' and knows it's a > problem in his use of gnulib.
I don't think this will be much of a problem in practice. We can assume maintainers will read the gnulib documentation so that they know what rpl_ is for. Briefly, defining strstr to rpl_strstr means "Do not use any library implementation of strstr, regardless of whether the library implements strstr." > 2) If the maintainer has not included the strstr module but uses the > strstr function and the installer does _not_ set _GL_CHECK_PORTABILITY: > Your proposal will activate the "extern char *strstr ..." declaration, > while mine won't. No, because @HAVE_DECL_STRSTR@ would be 1 in that case. gl_HEADER_STRING_H_DEFAULTS would set HAVE_DECL_STRSTR to 1 by default. It already does this for most of the HAVE_DECL_* symbols. The idea is to consistently handle all the symbols that we mess with in string.h.
