autoconf-patches
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]