Hi,
I found this bug while running "global -u -v" on a 64 bits system.
Without the bug:
[1/2] deleting tags of mlips/include/foo.h
[2/2] deleting tags of mlips/include/bar.h
[1/2] adding tags of mlips/include/foo.h
[2/2] adding tags of mlips/include/bar.h
When a very large 64 bits value is returned by sysconf, it is cast to
a negative int and the bug is triggered. Then global is just deleting
symbols instead:
[1/2] deleting tags of mlips/include/foo.h
[2/2] deleting tags of mlips/include/bar.h
This cause of this bug was very well hidden because negative values
were changed to zero. I cannot understand why: a limit of zero still
does not work, it just hides this bug.
Regards,
Marc
diff --git a/libutil/xargs.c b/libutil/xargs.c
index 94627dd..a1dba63 100644
--- a/libutil/xargs.c
+++ b/libutil/xargs.c
@@ -38,6 +38,7 @@
#include "xargs.h"
#if !defined(ARG_MAX) && defined(_SC_ARG_MAX)
+/* FIXME: in theory sysconf() can return -1L for unlimited */
#define ARG_MAX sysconf(_SC_ARG_MAX)
#endif
@@ -70,7 +71,7 @@ static XARGS *xargs_open_generic(const char *, int);
static int
exec_line_limit(int length)
{
- int limit = 0;
+ long limit = 0;
#ifdef ARG_MAX
/*
@@ -105,7 +106,8 @@ exec_line_limit(int length)
limit = 2047 - length - 80;
#endif
if (limit < 0)
- limit = 0;
+ die("Negative exec line limit = %ld", limit);
+
return limit;
}
/*
_______________________________________________
Bug-global mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-global
