On Fri, May 31, 2013 at 12:39 PM, Russ Allbery <[email protected]> wrote: > Zack Weinberg <[email protected]> writes: > > I *think* your patch would remove strings.h from the list of headers that > are probed by default by Autoconf, and hence remove HAVE_STRINGS_H from > the preprocessor directives set by Autoconf.
That's right. > If so, note that removing strings.h from the list of headers that are > probed by default will cause backwards compatibility issues. One still > must include strings.h (not string.h) according to POSIX in order to get > strcasecmp and friends, and some operating systems (specifically at least > some versions of FreeBSD) do actually enforce that and do not prototype > those functions in string.h. I'm quite sure there is code out there that > assumes that Autoconf will probe for strings.h as a side effect of other > probes and set HAVE_STRINGS_H, and therefore doesn't probe for it > explicitly. (I maintain some of it, in fact.) I had been under the impression that everything one still wanted out of strings.h was also specified to be in string.h (in particular both strcasecmp and ffs). I see now that this is wrong. For the short term I'm good with putting a conditional #include of strings.h and a probe for it back into AC_INCLUDES_DEFAULT (MSVC is the only common platform that doesn't seem to have it, but that's true even in the very latest version). However, I'd like to come up with a transition plan so we don't have to treat this as an almost-always-wanted header forever. We don't have any tooling for a "you need to start probing for this manually" warning, do we? An unconditional AC_DIAGNOSE would be spurious for most people... I'm also good with restoring compatibility AC_DEFINEs for the C90 headers (HAVE_STRING_H, HAVE_STDDEF_H, HAVE_STDLIB_H, I think that was all) just to be safe.
