[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/2] Modernize header checks
From: |
Eric Blake |
Subject: |
Re: [PATCH 0/2] Modernize header checks |
Date: |
Fri, 31 May 2013 11:19:42 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
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