This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] dwarf2read.c: Don't assume uint32_t is unsigned int on all hosts.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]