This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] dwarf2read.c: Don't assume uint32_t is unsigned int on all hosts.
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Doug Evans <dje at google dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 23 May 2013 12:59:00 +0100
- Subject: Re: [PATCH] dwarf2read.c: Don't assume uint32_t is unsigned int on all hosts.
- References: <20130521203421 dot 23721 dot 93618 dot stgit at brno dot lan> <CADPb22TzeQEanUGOMcFBJrStDYkk5zRUE2Fht_c_d5mQAYM7sw at mail dot gmail dot com> <519C932E dot 7000601 at redhat dot com> <CADPb22S0sYeTv+9_gsNO=3axHabLjgtwuyuNpyniLUfwwv9aCQ at mail dot gmail dot com> <519CEDF9 dot 7060000 at redhat dot com> <CADPb22Tw2b788uihCJjjnmKKGjgm525vmpThMzEHZ0fpSTqgzw at mail dot gmail dot com> <20130523055353 dot GC4017 at adacore dot com>
On 05/23/2013 06:53 AM, Joel Brobecker wrote:
>> I don't mind much how it's implemented. Remembering that there is
>> puint32 for the purpose of printing uint32's will stick in my memory
>> more than having to use pulongest.
>
> 'cannot believe I am saying this, but how about a puint32 macro
> that just renames pulongest?
If we ignore implementation details, can I take it you'd prefer
the puint32 direction then?
That means moving in the direction of ending up with
puint8,puint16,puint32,puint64,pint8,pint16,pint32,pint64,
pxint8,pxint16,pxint32,pxint64,etc.,etc.., right?
Essentially, inttypes.h done differently.
It seems we're setting precedent for how GDB will handle these
from here on, that's why it seems important to me to bikeshed it
now, rather that N times again whenever the next uint16_t/uint32_t/etc.
print appears. :-) Current options on the table:
#1 - Use inttypes.h format specifiers
PRId16/PRId32/PRIu16/PRIu32/PRIx16/PRIx32 etc. We import
inttypes from gnulib, so these are always available.
#2 - plongest/pulongest, and let the compiler zero/sign extend.
For hex printing use phex/phex_nz.
#3 - Add puint16/puint32/pint16/pint32/pxint16/pxint32 etc.,
similar in spirit to plongest/pulongest.
Votes, or other opinions? I seem to prefer #1 or #2, given
we end up with fewer infrastructure to maintain that way, but
I'll really go along with anything.
--
Pedro Alves