From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Keith Seitz'" <keiths@redhat.com>,
"'Patrick Monnerat'" <Patrick.Monnerat@datasphere.ch>
Cc: <insight@sourceware.org>, <roland@onevision.com>
Subject: RE: [PATCH] print format does not match argument type
Date: Fri, 13 Apr 2012 14:52:00 -0000 [thread overview]
Message-ID: <000001cd1984$fce97c30$f6bc7490$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <4F845F7E.1010603@redhat.com>
> -----Message d'origine-----
> De : insight-owner@sourceware.org [mailto:insight-owner@sourceware.org] De
> la part de Keith Seitz
> Envoyé : mardi 10 avril 2012 18:28
> À : Patrick Monnerat
> Cc : insight@sourceware.org; roland@onevision.com
> Objet : Re: [PATCH] print format does not match argument type
>
> On 04/10/2012 09:08 AM, Patrick Monnerat wrote:
>
> > I think I've found the universal (well: almost!) coding:
> >
> > Use format "%llx" and cast arg to (unsigned long long): This is C99 and
> > supported by MSVC, at least since 2005. Not OK for C89 :-(
>
> To be honest, I didn't even know that we did this. [The register code is
> some of the oldest code in insight.] Passing host memory addresses into
> the interpreter and back again as a string is just plain evil.
>
> The C code should create a map/hashtable and store the pointers to the
> types itself; then pass a string representation of the key into the
> interpreter.
>
> But for now, if your suggestion works (Roland will hopefully verify),
> then I say we go with that for the time being.
The gdb/utils.c function called host_address_to_string
was created to allow printing of host pointer
without need to bother with %llX or typecasts...
It does add a '0x' at the start of the
generated pchar, but I don't think that this is a big problem.
This second field (ar[1]) is probably added to avoid confusion between
type with same name...
Should we use this patch?
Pierre Muller
ChangeLog entry:
2012-04-13 Pierre Muller <muller@ics.u-strasbg.fr>
* generic/gdbtk-register.c (get_register_types): Use
host_address_to_string function to avoid use of "%lx" and
typecasts.
cvs diff: Diffing generic
Index: generic/gdbtk-register.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-register.c,v
retrieving revision 1.42
diff -u -p -r1.42 gdbtk-register.c
--- generic/gdbtk-register.c 30 Mar 2012 07:36:10 -0000 1.42
+++ generic/gdbtk-register.c 13 Apr 2012 14:42:56 -0000
@@ -239,7 +239,8 @@ get_register_types (int regnum, map_arg
{
Tcl_Obj *ar[3], *list;
char *buff;
- buff = xstrprintf ("%lx", (size_t)TYPE_FIELD_TYPE (reg_vtype, i));
+ buff = xstrprintf ("%s", host_address_to_string (
+ TYPE_FIELD_TYPE (reg_vtype, i)));
ar[0] = Tcl_NewStringObj (TYPE_FIELD_NAME (reg_vtype, i), -1);
ar[1] = Tcl_NewStringObj (buff, -1);
if (TYPE_CODE (TYPE_FIELD_TYPE (reg_vtype, i)) == TYPE_CODE_FLT)
@@ -255,7 +256,7 @@ get_register_types (int regnum, map_arg
{
Tcl_Obj *ar[3], *list;
char *buff;
- buff = xstrprintf ("%lx", (size_t)reg_vtype);
+ buff = xstrprintf ("%s", host_address_to_string (reg_vtype));
ar[0] = Tcl_NewStringObj (TYPE_NAME(reg_vtype), -1);
ar[1] = Tcl_NewStringObj (buff, -1);
if (TYPE_CODE (reg_vtype) == TYPE_CODE_FLT)
cvs diff: Diffing library
cvs diff: Diffing library/help
cvs diff: Diffing library/help/images
cvs diff: Diffing library/help/trace
cvs diff: Diffing library/images
cvs diff: Diffing library/images2
cvs diff: Diffing plugins
cvs diff: Diffing plugins/intel-pentium
cvs diff: Diffing plugins/rhabout
next prev parent reply other threads:[~2012-04-13 14:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 14:30 Roland Schwingel
2012-04-10 15:10 ` Patrick Monnerat
2012-04-10 16:08 ` Patrick Monnerat
2012-04-10 16:28 ` Keith Seitz
2012-04-13 14:52 ` Pierre Muller [this message]
2012-04-13 15:18 ` Keith Seitz
2012-04-13 15:25 ` Pierre Muller
-- strict thread matches above, loose matches on Subject: below --
2012-04-11 11:38 Roland Schwingel
2012-04-11 17:24 ` Patrick Monnerat
2012-04-10 16:59 Roland Schwingel
2012-04-05 16:34 Patrick Monnerat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001cd1984$fce97c30$f6bc7490$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=Patrick.Monnerat@datasphere.ch \
--cc=insight@sourceware.org \
--cc=keiths@redhat.com \
--cc=roland@onevision.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).