[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-04 Thread Stepan Kasal
Hello, On Fri, Jun 03, 2005 at 05:53:00PM +0200, Bruno Haible wrote: > AS_TR_* are not documented in the autoconf manual You are right. I have to start by documenting AS_TR_SH, AS_TR_CPP, AS_LITERAL_IF and m4_fatal. Then I can resubmit the patch. > AC_TRY_COMPILE is shorter and more mnemonic t

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread Bruno Haible
Derek Price wrote: > Actually, `m4_popdef' is documented explicitly in my Autoconf 2.59 > manual. The Autoconf 2.59 manual also contains the following text: > > With a few exceptions, all the M4 native macros are moved in the `m4_' > pseudo-namespace, e.g., M4sugar renames `define' as `m4_

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread Derek Price
Bruno Haible wrote: >>- use m4_pushdef/m4_popdef instead of define/undefine >>- use AS_TR_* instead of raw m4_translit >> >> > >m4_pushdef, m4_popdef, AS_TR_* are not documented in the autoconf manual >(latest release, 2.59). In consequence, their meaning can change, or they >can go away entir

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread James Youngman
On Fri, Jun 03, 2005 at 05:54:29PM +0200, Bruno Haible wrote: > James Youngman wrote: > > HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is > > not. > > Have you seen a system where this is the case? No, never. > The autoconf test assumes that when MIN is defined in a heade

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread Bruno Haible
Stepan Kasal wrote: > I read your macro in minmax.m4. I'd like to propose some > changes in style: > - avoid the obsoleted AC_TRY_COMPILE AC_TRY_COMPILE is shorter and more mnemonic than the *_IFELSE macros. > - use m4_pushdef/m4_popdef instead of define/undefine > - use AS_TR_* instead of raw m

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread Bruno Haible
James Youngman wrote: > HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is > not. Have you seen a system where this is the case? The autoconf test assumes that when MIN is defined in a header, MAX will be defined as well, and vice versa. Bruno ___

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread James Youngman
On Fri, Jun 03, 2005 at 01:54:01PM +0200, Stepan Kasal wrote: > +gl_CACHE_VAR, > +[AC_COMPILE_IFELSE([#include <$1> > + int x = MIN (42, 17);], > + [gl_CACHE_VAR=yes], > + [gl_CACHE_VAR=no])]) > + if test $gl_CACHE_VAR = yes; then > +AC_DEFINE([HAVE_MIN

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread Stepan Kasal
Hi Bruno, I read your macro in minmax.m4. I'd like to propose some changes in style: - avoid the obsoleted AC_TRY_COMPILE - use m4_pushdef/m4_popdef instead of define/undefine - use AS_TR_* instead of raw m4_translit A patch with my proposal is attached; it's not tested, sorry. Could you please

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-05-23 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: >I therefore commit this patch. Thanks, Bruno. Thank, Paul. Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkeZjLD1OTBfyMaQRAgmpAKDl

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-05-23 Thread Bruno Haible
Paul Eggert wrote: > Second, suppose and have conflicting > definitions of MIN and MAX? To work around the latter potential > problem you can #undef MIN and MAX after including . In this case we'll still get warnings, either when the user does #include #include or when he does #in

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-05-23 Thread Bruno Haible
Derek Price wrote: > >First, the $gl_* variables should be cached, with AC_CACHE_CHECK. > > Done. Thanks. > + AC_CACHE_CHECK([whether defines MIN & MAX], > + gl_limits_h_has_minmax, Cache variables need to have _cv_ in their name. So one needs to change this to gl_cv_limits_h_ha