[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 */