On 05/31/2013 11:07 AM, Eric Blake wrote: >> 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.) > > 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.
That said, would it hurt if autoconf just unconditionally defined the macros that were previously conditionally defined by a probe, so that code that was relying on HAVE_STRINGS_H instead of blind inclusion will still compile? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
