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] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays]


> Both before and it gets a bit worse after.  There should be a union with
> fields for each very specific TYPE_CODE_*.

I would tend to agree, but I haven't thought about it much. I might be
biased by the fact that Ada's use of variant record is relatively common.
For instance, our structure implemented in Ada might roughly look like this:


   type GDB_Type_Kind is (Type_Code_Enum, Type_Code_Range, Type_Code_Array, ...
   --  All possible kinds of types.

   type GDB_Type (Kind : GDB_Type_Kind) is
      Boolean : Stub;
      Boolean : Incomplete;
      --  ... Any other field that's common to all types
      case Kind is
         when Type_Code_Enum =>
            Enumerates : List_Of_Enumerates;
         when Type_Code_Range | Type_Code_Int =>
            Low, High : Bound_Type;
         when Type_Code_Array =>
            Element_Type : GDB_Type_Pointer;
            Index : Range_Type_Pointer;
         when ... =>
            [etc]

As you suggest, this is easily achievable in C as well by using unions,
with the one difference is that Ada does some access check and makes sure
that we access fields that are consistent with the discriminant (field
named "Kind" in the example above).

I think that this would help clarify the whole structure, and tell us
what is and what is not used for each kind of type.  But I am not sure
of the drawbacks... For sure this would be a pretty significant change
througout GDB, but maybe an interesting one.

(that was my windy way of saying: I think I agree)

-- 
Joel


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