update minmax.m4
Hello Bruno. I think it's time to re-submit my patch to minmax.m4. A new version of the patch is attached to this mail. Again, it features: > - use m4_pushdef/m4_popdef instead of define/undefine As I explained before, you cannot inadvertently undefine([HEADER]). > - avoid the obsoleted AC_TRY_COMPILE Some people run "autoconf -W obsolete", and the macros from gnulib shouldn't spoil it. > - use AS_TR_* instead of raw m4_translit Do you see any problem with this patch? All used macros are now documented. Have a nice day, Stepan 2005-06-30 Stepan Kasal <[EMAIL PROTECTED]> * minmax.m4 (gl_MINMAX_IN_HEADER): Use m4_pushdef/m4_popdef. Also use more modern macros. Index: m4/minmax.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/minmax.m4,v retrieving revision 1.1 diff -u -r1.1 minmax.m4 --- m4/minmax.m423 May 2005 10:25:53 - 1.1 +++ m4/minmax.m430 Jun 2005 16:36:01 - @@ -17,22 +17,21 @@ ]) dnl gl_MINMAX_IN_HEADER(HEADER) +dnl The parameter has to be a literal header name; it cannot be macro, +dnl nor a shell variable. AC_DEFUN([gl_MINMAX_IN_HEADER], [ - define([header],[translit([$1],[./-], - [___])]) - define([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-], - [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])]) + AC_PREREQ(2.50) + m4_pushdef([gl_CACHE_VAR], gl_cv_minmax_in_[]AS_TR_SH([$1])) AC_CACHE_CHECK([whether <$1> defines MIN and MAX], -[gl_cv_minmax_in_]header, -[AC_TRY_COMPILE([#include <$1> -int x = MIN (42, 17);], [], - [gl_cv_minmax_in_]header[=yes], - [gl_cv_minmax_in_]header[=no])]) - if test $gl_cv_minmax_in_[]header = yes; then -AC_DEFINE([HAVE_MINMAX_IN_]HEADER, 1, +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_MINMAX_IN_]AS_TR_CPP([$1]), 1, [Define to 1 if <$1> defines the MIN and MAX macros.]) fi - undefine([HEADER]) - undefine([header]) + m4_popdef([gl_CACHE_VAR]) ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: an archive of POSIX compat files ?
Hi,
I committed the patch attached to this mail.
Stepan
2005-06-30 Stepan Kasal <[EMAIL PROTECTED]>
* doc/autoconf.texi (Generic Functions): Mention the Gnulib project.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.921
diff -u -r1.921 autoconf.texi
--- doc/autoconf.texi 29 Jun 2005 10:47:38 - 1.921
+++ doc/autoconf.texi 30 Jun 2005 12:29:04 -
@@ -4564,6 +4564,12 @@
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
+Suitable replacements for many such problem functions are available from
[EMAIL PROTECTED]://www.gnu.org/software/gnulib/, Gnulib}, which aims to
+provide a centralized repository of such portability functions (among
+other things). The source files are available online, under various
+licences, mostly GNU GPL or GNU LGPL.
+
@defmac AC_LIBOBJ (@var{function})
@acindex{LIBOBJ}
@ovindex LIBOBJS
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: proposal: lib/verify.h
Jim Meyering <[EMAIL PROTECTED]> writes:
> #define GL_CONCAT...
> #define VERIFY(assertion) \
> struct GL_CONCAT (compile_time_assert_, __LINE__) \
> { char a[(assertion) ? 1 : -1]; }
This trick won't work if VERIFY is used in two different files with
the same line number. Typically the problem would occur if there are
multiple headers that use VERIFY, or a header and a source file that
both use VERIFY.
Admittedly it's a bit of a pain to have to come up with a name for
each requirement, as is the case with mktime.c now.
So, how about if we simply dump the named-requirement variant, and
stick only with the unnamed variant? If there is a need to verify
stuff at the top level, we can do something like this:
static inline void
verify_mktime_requirements (void)
{
verify (TYPE_IS_INTEGER (time_t));
verify (TYPE_TWOS_COMPLEMENT (int));
...
}
(The "inline" is to pacify GCC so that it doesn't warn about the
unused function.)
One other thought: "assert" uses lower-case letters, and I'd
like "verify" to do so too.
So, how about the following macro instead?
/* Verify REQUIREMENT at compile-time, as an expression.
Unlike assert, there is no run-time overhead.
Return void. */
#define verify(requirement) \
((void) sizeof (struct { char a[(requirement) ? 1 : -1]; }))
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: proposal: lib/verify.h
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> #define GL_CONCAT...
>> #define VERIFY(assertion) \
>> struct GL_CONCAT (compile_time_assert_, __LINE__) \
>> { char a[(assertion) ? 1 : -1]; }
>
> This trick won't work if VERIFY is used in two different files with
> the same line number. Typically the problem would occur if there are
> multiple headers that use VERIFY, or a header and a source file that
> both use VERIFY.
That's true, but maybe it won't matter in practice?
All of my uses of the statement-form have ended up being
expanded in .c files.
> Admittedly it's a bit of a pain to have to come up with a name for
> each requirement, as is the case with mktime.c now.
>
> So, how about if we simply dump the named-requirement variant, and
> stick only with the unnamed variant? If there is a need to verify
> stuff at the top level, we can do something like this:
>
> static inline void
> verify_mktime_requirements (void)
> {
> verify (TYPE_IS_INTEGER (time_t));
> verify (TYPE_TWOS_COMPLEMENT (int));
> ...
> }
That still requires coming up with a name: the function name.
I want something so that my recent patch to ls.c (below)
stays concise and continues to work.
Why not continue on with two macros?
If someone tries to use the statement form but cannot
because of a conflict, they can then resort to choosing
a name and adding a static inline function.
> (The "inline" is to pacify GCC so that it doesn't warn about the
> unused function.)
>
> One other thought: "assert" uses lower-case letters, and I'd
> like "verify" to do so too.
Sure. Lower case does look better.
> So, how about the following macro instead?
>
> /* Verify REQUIREMENT at compile-time, as an expression.
>Unlike assert, there is no run-time overhead.
>Return void. */
> #define verify(requirement) \
> ((void) sizeof (struct { char a[(requirement) ? 1 : -1]; }))
Index: src/ls.c
===
RCS file: /fetish/cu/src/ls.c,v
retrieving revision 1.390
retrieving revision 1.391
diff -u -p -u -1 -r1.390 -r1.391
--- src/ls.c29 Jun 2005 10:03:10 - 1.390
+++ src/ls.c30 Jun 2005 16:47:58 - 1.391
@@ -500,2 +499,3 @@ static enum indicator_style const indica
};
+ARGMATCH_VERIFY (indicator_style_args, indicator_style_types);
@@ -797,2 +796,3 @@ static enum format const format_types[]
};
+ARGMATCH_VERIFY (format_args, format_types);
@@ -807,2 +806,3 @@ static enum sort_type const sort_types[]
};
+ARGMATCH_VERIFY (sort_args, sort_types);
@@ -817,2 +816,3 @@ static enum time_type const time_types[]
};
+ARGMATCH_VERIFY (time_args, time_types);
@@ -832,2 +831,3 @@ static enum color_type const color_types
};
+ARGMATCH_VERIFY (color_args, color_types);
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
