[repost -
apologies, apparently my first one was unintentionally a
followup to
another thread]
If you ever do
an opal_output() with a "%p" in the format string,
guess_strlen() can
segfault because it neglects to consume the corresponding
argument, causing
subsequent "%s" in the same format string to blow up in
strlen() on a bad
address. Any objections to the following patch to add %p
support? If I were to check this in, is there some automated build
process
that will inform me I broke the build on, say, 43-bit Zurix machines
?
If the llarg = (uintptr_t) business is scary (it is to me a little), a
much
more conservative would be: len += 2*sizeof(void
*)+2;
-reese
Index:
opal/util/printf.c
===================================================================
---
opal/util/printf.c (revision 13271)
+++ opal/util/printf.c
(working copy)
@@ -45,6 +45,7 @@
int
iarg;
int len;
long
larg;
+ long long llarg;
/*
Start off with a fudge factor of 128 to handle the % escapes
that
we aren't calculating here
*/
@@ -90,6 +91,17
@@
} while (0 !=
iarg);
break;
+
case
'p':
+
sarg = va_arg(ap, char
*);
+
llarg = (uintptr_t)
sarg;
+
len +=2; /* allow for "0x"
*/
+
/* Now get the log16
*/
+
do
{
+
++len;
+
llarg /=
16;
+
} while (0 !=
llarg);
+
break;
+
case
'f':
farg = (float)va_arg(ap,
int);
/* Alloc for minus sign */