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), 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 */
