I think this is a reasonable thing to commit. However, keep in mind
that %p isn't totally portable. I think it should be good on all the
platforms GM/MX support, but probably not a great idea to use it in
the general codebase.
But still reasonable to make the code at this level understand it so
that you can use %p in components that will only be used on platforms
where it's likely supported...
I actually think the
So commit away ;)
Brian
On Jan 24, 2007, at 4:09 PM, Reese Faucette wrote:
[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 */
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Brian Barrett
Open MPI Team, CCS-1
Los Alamos National Laboratory
