This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/6851] printf %c
- From: "joshua dot i dot stone at intel dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 9 Sep 2008 01:16:20 -0000
- Subject: [Bug translator/6851] printf %c
- References: <20080820220001.6851.jkenisto@us.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From joshua dot i dot stone at intel dot com 2008-09-09 01:16 -------
(In reply to comment #0)
> But in both cases, the %#x specifier following the %c specifier in the
> same format string gets it wrong -- the byte order is reversed. Given
> the same value, %#x alone gets it right.
The byte order is not reversed -- it's just picking up bytes left over from the
char. The translator is pushing an int64_t, but the print runtime is only
pulling off an int for %c formats. You can fix it in either place, e.g.:
---- begin 1 ----
diff --git a/runtime/vsprintf.c b/runtime/vsprintf.c
index 4ffcf72..f807c4f 100644
--- a/runtime/vsprintf.c
+++ b/runtime/vsprintf.c
@@ -392,7 +392,7 @@ int _stp_vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
++str;
}
}
- c = (unsigned char) va_arg(args, int);
+ c = (unsigned char) va_arg(args, int64_t);
if (str <= end)
*str = c;
++str;
---- end 1 ----
OR
---- begin 2 ----
diff --git a/translate.cxx b/translate.cxx
index 2fe3331..4f91e80 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -4193,6 +4193,9 @@ c_unparser::visit_print_format (print_format* e)
/* The type of the %m argument is 'char*'. */
if (components[i].type == print_format::conv_memory)
o->line() << ", (char*)(uintptr_t)" << tmp[arg_ix++].value();
+ /* The type of the %c argument is 'char*'. */
+ else if (components[i].type == print_format::conv_char)
+ o->line() << ", (int)" << tmp[arg_ix++].value();
else
o->line() << ", " << tmp[arg_ix++].value();
}
---- end 2 ----
Changing the runtime makes me a little nervous about unseen effects, so the
second patch may be the safer route.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6851
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.