Re: [PATCH 0/2] Modernize header checks
Zack Weinberg za...@panix.com writes: Second, it cleans up AC_INCLUDES_DEFAULT and all the other canned tests so that they don't waste time checking for ISO C90 headers, which are now ubiquitous (stddef.h, stdlib.h, string.h, wchar.h, wctype.h, locale.h, time.h) and don't use pre-standard headers that were replaced by C90 headers at all (memory.h and strings.h). I *think* your patch would remove strings.h from the list of headers that are probed by default by Autoconf, and hence remove HAVE_STRINGS_H from the preprocessor directives set by Autoconf. 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.) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 0/2] Modernize header checks
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
Re: [PATCH 0/2] Modernize header checks
Eric Blake ebl...@redhat.com writes: 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. Sure, I can add the explicit probe for strings.h to my code or drop the #ifdef depending on the portability requirements (and in fact will do so regardless, since whether or not this change is made it's a good idea). My point wasn't that, but rather that this change will break backward compatibility for Autoconf users, and I wanted to make sure that people were aware of that. There is code that includes strings.h protected by #ifdef HAVE_STRINGS_H which currently compiles correctly and will stop compiling correctly after the configure script is rebuilt with this change. All of the other changes that Zack discussed look backward-compatible to me except in the area of portability to entirely obsolete systems. This one stood out because it would break compilation of some packages on modern, maintained FreeBSD systems because it changes current assumptions about what the standard Autoconf header probes do. This behavior is not currently clearly documented, but I will point out that the current documentation of AC_INCLUDES_DEFAULT shows use of the HAVE_STRINGS_H define without any mention of any other required checks. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 0/2] Modernize header checks
Eric Blake ebl...@redhat.com writes: 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? That would certainly resolve my concern. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 2/2] Modernize AC_INCLUDES_DEFAULT and friends.
On 05/30/2013 03:19 PM, Zack Weinberg wrote: * lib/autoconf/headers.m4 (_AC_INCLUDES_DEFAULT_REQUIREMENTS): Include stddef.h, stdlib.h, and string.h unconditionally. Don't include strings.h or memory.h at all. strings.h is still a standardized header, its just that the standards assigned it very little content. +- AC_INCLUDES_DEFAULT has been streamlined. It now assumes that + ISO C90 headers are available unconditionally (stddef.h, stdio.h, + stdlib.h, string.h) and does not use pre-standard headers at all + (memory.h, strings.h). Therefore, this NEWS entry needs to be tweaked for accuracy (only memory.h is pre-standard), which may also mean tweaking your code. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
On Fri, May 31, 2013 at 12:39 PM, Russ Allbery r...@stanford.edu wrote: Zack Weinberg za...@panix.com writes: I *think* your patch would remove strings.h from the list of headers that are probed by default by Autoconf, and hence remove HAVE_STRINGS_H from the preprocessor directives set by Autoconf. That's right. 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.) 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. 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... 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.
Re: [PATCH 0/2] Modernize header checks
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 Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
On 2013-05-31 19:19, Eric Blake wrote: 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? How would one do to be portable to both some versions of FreeBSD and MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs HAVE_STRINGS_H to be defined and one needs to not have it defined. Sounds evil to unconditionally define it under those circumstances. Or have I misunderstood something? Cheers, Peter
Re: [PATCH 0/2] Modernize header checks
On 05/31/2013 03:26 PM, Peter Rosin wrote:
On 2013-05-31 19:19, Eric Blake wrote:
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?
How would one do to be portable to both some versions of FreeBSD and
MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs
HAVE_STRINGS_H to be defined and one needs to not have it defined.
Sounds evil to unconditionally define it under those circumstances. Or
have I misunderstood something?
Portable only to open toolchains, your choice of:
1. Simplest:
#include strings.h
void foo() { strcasecmp(a, b); }
2. Verbose:
#include string.h
#if HAVE_STRINGS_H
# include strings.h
#endif
void foo() { strcasecmp(a, b); }
Portable to MSVC toolchains:
3. Verbose:
#include string.h
#if HAVE_STRINGS_H
# include strings.h
#endif
void foo() { strcasecmp(a, b); }
The upshot is that if autoconf only cares about open toolchains (such as
gcc on mingw when porting code to Windows), then it can unconditionally
define HAVE_STRINGS_H (it must define this macro for back-compat to
existing code that only includes strings.h inside that test). But if
autoconf still wants to cater to MSVC, then it must have a way to
specify that the existence of strings.h must be probed. This way does
not have to be default; most packages need a LOT more work before they
could compile under MSVC in the first place, so asking users that care
about such setups to modify configure.ac to set some witness variable in
order to force a probe instead of a blind define seems okay to me.
Personally, I don't care if any of my packages ever compile under MSVC -
that's due in part to Microsoft's lack of regards towards standards and
unwillingness to provide free tools (free license, not free price); in
part due to the fact that gcc on mingw does just as well; and in part
due to the fact that no one who does care has ever submitted a patch to
any of my project mailing lists even trying to get that to work.
Therefore, I would argue that future autoconf needs a way to minimize
useless probing for strings.h, and it would be nicer (in my eyes) if
this mode were the default; although I could also be persuaded that it
is safer to have the no-probe mode only if I add a witness macro to my
configure.ac.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
Peter Rosin p...@lysator.liu.se writes: On 2013-05-31 19:19, Eric Blake wrote: 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? How would one do to be portable to both some versions of FreeBSD and MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs HAVE_STRINGS_H to be defined and one needs to not have it defined. Sounds evil to unconditionally define it under those circumstances. Or have I misunderstood something? Autoconf doesn't work with MSVC directly so far as I know. All of the packages I have that are ported to MSVC have a separate hand-written config.h that's used for MSVC builds, and in that file one simply doesn't define HAVE_STRINGS_H. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 0/2] Modernize header checks
On 2013-06-01 00:06, Russ Allbery wrote: Peter Rosin p...@lysator.liu.se writes: On 2013-05-31 19:19, Eric Blake wrote: 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? How would one do to be portable to both some versions of FreeBSD and MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs HAVE_STRINGS_H to be defined and one needs to not have it defined. Sounds evil to unconditionally define it under those circumstances. Or have I misunderstood something? Autoconf doesn't work with MSVC directly so far as I know. All of the packages I have that are ported to MSVC have a separate hand-written config.h that's used for MSVC builds, and in that file one simply doesn't define HAVE_STRINGS_H. What do you mean directly? MSYS can drive a build using MSVC as toolchain (instead of MinGW) just fine. I do it all the time. Cheers, Peter
