Re: [PATCHv2 2/2] gdb/python: add Type.signedness attribute

[Andrew Burgess <aburgess@redhat.com>]

* Simon Marchi <simon.marchi@polymtl.ca> [2021-12-07 22:13:40 -0500]:

> > +@vindex TYPE_SIGNEDNESS_NONE
> > +@item gdb.TYPE_SIGNEDNESS_NONE
> > +This type is considered neither signed, or unsigned.  This applies to
> > +all non-scalar types (e.g.@: c language structs), but can sometimes be
> > +the value return for scalar type, one example of where this can be
> > +seen is in C++, where @code{char}, @code{signed char}, and
> > +@code{unsigned char} are all considered distinct types.
> 
> I'm curious, why would type `unsigned char` not return
> gdb.TYPE_SIGNEDNESS_UNSIGNED?  I see the corresponding code in
> gdbtypes.c, with the m_flag_nosign flag, so I understand that you would
> implementation the Python binding based on that, but I am wondering
> about the historical reason.

Sorry, but I don't understand the question.  I'm assuming you actually
meant to ask a slightly different question, but, just for clarity,
I'll answer your actual question first.  I added these declarations to
gdb.python/py-type.c:

  unsigned char global_unsigned_char;
  char global_char;
  signed char global_signed_char;

And these tests to gdb.python/py-type.exp:

  gdb_test "python print (gdb.parse_and_eval ('global_unsigned_char').type.signedness == gdb.TYPE_SIGNEDNESS_UNSIGNED)" "True"
  gdb_test "python print (gdb.parse_and_eval ('global_char').type.signedness == gdb.TYPE_SIGNEDNESS_NONE)" "True"
  gdb_test "python print (gdb.parse_and_eval ('global_signed_char').type.signedness == gdb.TYPE_SIGNEDNESS_SIGNED)" "True"

So you can see that `unsigned char` does return
gdb.TYPE_SIGNEDNESS_UNSIGNED.

If your question is why would `char` not return UNSIGNED, then it
appears that plain char is not defined as unsigned in the standard.
This appears to be described in 6.2.5/15 of the C language draft that
I have to hand:

  "The three types char, signed char, and unsigned char are
   collectively called the character types. The implementation shall
   define char to have the same range, representation, and behavior as
   either signed char or unsigned char.)"

But I guess the problem is that whether char is signed or unsigned is
not encoded into the DWARF.

I'll update the Python documentation to talk about C/C++ rather than
just C++ w.r.t. this state.

Hope that helps,

Andrew