This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFA] New function type_code_name.


klee@apple.com said:
> This patch moves the type-printing code from recursive_dump_type()
> into  the new function type_code_name().  It's handy when one wants to
> use  the type code of a type in debugging or warning/error messages.


>         * gdbtypes.h (type_code_name): Add prototype.
>         * gdbtypes.c (type_code_name): New function.  Returns a
>         constant string containing the ASCII name of the type code.
>         (recursive_dump_type): Use type_code_name.



Hmm, I think this could be much cleaner if we considered moving towards 
GCC's model of having a gdbtype.def file which defined the type the 
strings together.  We could then build up an array of strings that is kept 
in sync with the enum definition.  Something like

gdbtype.def:

DEF_TYPE (TYPE_CODE_INT, "TYPE_CODE_INT", anything else needed by all 
types)

DEF_TYPE (TYPE_CODE_TYPEDEF, "TYPE_CODE_TYPEDEF", ...)

etc

then to use it, do

#define DEF_TYPE(X,Y,Z) X,

enum type_code {
#include "gdbtype.def"
  TYPE_CODE_NUM_TYPES
};

#undef DEF_TYPE

#define DEF_TYPE(X,Y,Z) Y,
const char char *const type_code_names[] = {
#include "gdbtype.def"
};

You can then look up the type name simply with

	if (type_code_number < TYPE_CODE_NUM_TYPES)
	  type_name = type_code_names[type_code_number];
	else
	  type_name = "INVALID TYPE";

and adding a new type (should we need to) is trivial.


R.




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