[Top][All Lists]

[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 12:03:39 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

On 05/31/2013 11:51 AM, Zack Weinberg wrote:
> 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.

POSIX allows (but not requires) strcasecmp to be made available in
<string.h> (basically, the entire str* namespace is reserved for use by
<string.h> - so BSD's efforts to hide strcasecmp from string.h when
strictly-conforming may be a bit too harsh); but POSIX does NOT allow
ffs to be made available in <string.h>.  Then again, most users
specifically ask for non-POSIX extensions via AC_USE_SYSTEM_EXTENSIONS,
at which point namespace pollution of ffs via string.h is fair game.
But at the end of the day, the only portable way to rely on strcasecmp
or ffs is to use <strings.h>.

> 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...

ifnames(1) is part of the Autoconf package, and SHOULD be the tool that
does this warning.  But it hasn't seen much use or much love lately.

> 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.

Yes, any macros that were previously defined on always-successful probes
must continue to be defined even after your cleanup.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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