-{
- TYPE_CODE_UNDEF, /* Not used; catches errors */
- TYPE_CODE_PTR, /* Pointer type */
- TYPE_CODE_ARRAY, /* Array type with lower & upper bounds. */
- TYPE_CODE_STRUCT, /* C struct or Pascal record */
- TYPE_CODE_UNION, /* C union or Pascal variant part */
- TYPE_CODE_ENUM, /* Enumeration type */
- TYPE_CODE_FUNC, /* Function type */
- TYPE_CODE_INT, /* Integer type */
-
- /* Floating type. This is *NOT* a complex type. Complex types, when
- we have them, will have their own type code (or TYPE_CODE_ERROR if
- we can parse a complex type but not manipulate it). There are parts
- of GDB which bogusly assume that TYPE_CODE_FLT can mean complex. */
- TYPE_CODE_FLT,
-
- /* Void type (values zero length; the length field is ignored). */
- TYPE_CODE_VOID,
-
- TYPE_CODE_SET, /* Pascal sets */
- TYPE_CODE_RANGE, /* Range (integers within spec'd bounds) */
-
- /* A string type which is like an array of character but prints
- differently (at least for CHILL). It does not contain a length
- field as Pascal strings (for many Pascals, anyway) do; if we want
- to deal with such strings, we should use a new type code. */
- TYPE_CODE_STRING,
-
- /* String of bits; like TYPE_CODE_SET but prints differently (at least
- for CHILL). */
- TYPE_CODE_BITSTRING,
-
- /* Unknown type. The length field is valid if we were able to
- deduce that much about the type, or 0 if we don't even know that. */
- TYPE_CODE_ERROR,
-
- /* C++ */
- TYPE_CODE_MEMBER, /* Member type */
- TYPE_CODE_METHOD, /* Method type */
- TYPE_CODE_REF, /* C++ Reference types */
-
- /* Modula-2 */
- TYPE_CODE_CHAR, /* *real* character type */
- TYPE_CODE_BOOL /* BOOLEAN type */
-};
+ {
+ TYPE_CODE_UNDEF, /* Not used; catches errors */
+ TYPE_CODE_PTR, /* Pointer type */
+
+ /* Array type with lower & upper bounds.
+
+ Regardless of the language, GDB represents multidimensional
+ array types the way C does: as arrays of arrays. So an
+ instance of a GDB array type T can always be seen as a series
+ of instances of TYPE_TARGET_TYPE (T) laid out sequentially in
+ memory.
+
+ Row-major languages like C lay out multi-dimensional arrays so
+ that incrementing the rightmost index in a subscripting
+ expression results in the smallest change in the address of the
+ element referred to. Column-major languages like Fortran lay
+ them out so that incrementing the leftmost index results in the
+ smallest change.
+
+ This means that, in column-major languages, working our way
+ from type to target type corresponds to working through indices
+ from right to left, not left to right. */
+ TYPE_CODE_ARRAY,
+
+ TYPE_CODE_STRUCT, /* C struct or Pascal record */
+ TYPE_CODE_UNION, /* C union or Pascal variant part */
+ TYPE_CODE_ENUM, /* Enumeration type */
+ TYPE_CODE_FLAGS, /* Bit flags type */
+ TYPE_CODE_FUNC, /* Function type */
+ TYPE_CODE_INT, /* Integer type */
+
+ /* Floating type. This is *NOT* a complex type. Beware, there are parts
+ of GDB which bogusly assume that TYPE_CODE_FLT can mean complex. */
+ TYPE_CODE_FLT,
+
+ /* Void type. The length field specifies the length (probably always
+ one) which is used in pointer arithmetic involving pointers to
+ this type, but actually dereferencing such a pointer is invalid;
+ a void type has no length and no actual representation in memory
+ or registers. A pointer to a void type is a generic pointer. */
+ TYPE_CODE_VOID,
+
+ TYPE_CODE_SET, /* Pascal sets */
+ TYPE_CODE_RANGE, /* Range (integers within spec'd bounds) */
+
+ /* A string type which is like an array of character but prints
+ differently (at least for (the deleted) CHILL). It does not
+ contain a length field as Pascal strings (for many Pascals,
+ anyway) do; if we want to deal with such strings, we should use
+ a new type code. */
+ TYPE_CODE_STRING,
+
+ /* String of bits; like TYPE_CODE_SET but prints differently (at
+ least for (the deleted) CHILL). */
+ TYPE_CODE_BITSTRING,
+
+ /* Unknown type. The length field is valid if we were able to
+ deduce that much about the type, or 0 if we don't even know that. */
+ TYPE_CODE_ERROR,
+
+ /* C++ */
+ TYPE_CODE_METHOD, /* Method type */
+
+ /* Pointer-to-member-function type. This describes how to access a
+ particular member function of a class (possibly a virtual
+ member function). The representation may vary between different
+ C++ ABIs. */
+ TYPE_CODE_METHODPTR,
+
+ /* Pointer-to-member type. This is the offset within a class to some
+ particular data member. The only currently supported representation
+ uses an unbiased offset, with -1 representing NULL; this is used
+ by the Itanium C++ ABI (used by GCC on all platforms). */
+ TYPE_CODE_MEMBERPTR,
+
+ TYPE_CODE_REF, /* C++ Reference types */
+
+ TYPE_CODE_CHAR, /* *real* character type */
+
+ /* Boolean type. 0 is false, 1 is true, and other values are non-boolean
+ (e.g. FORTRAN "logical" used as unsigned int). */
+ TYPE_CODE_BOOL,
+
+ /* Fortran */
+ TYPE_CODE_COMPLEX, /* Complex float */
+
+ TYPE_CODE_TYPEDEF,
+ TYPE_CODE_TEMPLATE, /* C++ template */
+ TYPE_CODE_TEMPLATE_ARG, /* C++ template arg */
+
+ TYPE_CODE_NAMESPACE, /* C++ namespace. */
+
+ TYPE_CODE_DECFLOAT, /* Decimal floating point. */
+
+ /* Internal function type. */
+ TYPE_CODE_INTERNAL_FUNCTION
+ };