Re: [PATCH 0/2] Modernize header checks

Eric Blake <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.patches
Organization Red Hat, Inc.
Message-ID <[email protected]>
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 http://libvirt.org
signature.asc (application/pgp-signature, 621 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJRqOX7AAoJEKeha0olJ0NqvPkIAKAuKOfYiqw9N4Zr++8vtgRW
512rHI2Mm4aiecWIG4O2rxTmxJix+GMQ/zyNt4XoJptHnViqMlHSh66NVKwGpqEx
kcOniQMJOGb+Lus5iB02cMx+HrWnWz05P29LlgJrchMdYw0sMjqXgWuN9sX9bbdo
BIiLCGOdTK8joGkQfF3vUSDE+0LvT6bUazytbI3eq1WZvpmSonxNx55ru/4dp7c5
o4vEq2LhhGNlEomoiPA9gHhzBBmTwi+FdI9q80hBZdVaj2wermafG1c9KSt2izWM
JdOYGmxc+SWus5bR6y8KmwH3DpGSCXSTr5bXZgAYGRmV50BnZzx0XRj2+Q6ov6Y=
=Fxik
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.