Eric Blake <ebl...@redhat.com> writes: > Yes, there is a bunch of code that non-portably assumes they can use > strcasecmp or ffs without including <strings.h>. On the other hand, > <strings.h> is available on pretty much ALL platforms that use free > software compilers (according to gnulib, only ancient Minix 3.1.8 and > non-free MSVC 9 have problems with assuming <strings.h> exists and is > self-contained; but mingw does not have this issue). Thus, you > generally don't need to use HAVE_STRINGS_H, but can just blindly include > it, unless your package is trying to be portable to a rather unforgiving > toolchain.
Sure, I can add the explicit probe for strings.h to my code or drop the #ifdef depending on the portability requirements (and in fact will do so regardless, since whether or not this change is made it's a good idea). My point wasn't that, but rather that this change will break backward compatibility for Autoconf users, and I wanted to make sure that people were aware of that. There is code that includes strings.h protected by #ifdef HAVE_STRINGS_H which currently compiles correctly and will stop compiling correctly after the configure script is rebuilt with this change. All of the other changes that Zack discussed look backward-compatible to me except in the area of portability to entirely obsolete systems. This one stood out because it would break compilation of some packages on modern, maintained FreeBSD systems because it changes current assumptions about what the standard Autoconf header probes do. This behavior is not currently clearly documented, but I will point out that the current documentation of AC_INCLUDES_DEFAULT shows use of the HAVE_STRINGS_H define without any mention of any other required checks. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
