Re: portability checks, errors and warnings

[Paul Eggert]

Bruno Haible <address@hidden> 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.