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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
