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: [rfc][19/37] Eliminate builtin_type_ macros: Ada range type handling


> > It just occured to me that, since this is a TYPE_CODE_RANGE, can't
> > we just use its type? A TYPE_CODE_RANGE should always be some kind
> > of "integer" type, so why not use that when calling value_from_longest?
> > I have this awful feeling that we're missing something, but I don't
> > see what. Do you see anything wrong with that?

First, I need to correct myself - ranges are not just for integral
types. You can have a range over any discrete type, which means
things like this:

   type Digit is (Zero, One, Two, ...);
   subtype Binary is Digit range (Zero .. One);

In this case, Binary would be defined as a subrange of the enumeration
type. However, after thinking about it awhile, I don't think that
enumeration types are that different from integral types in terms
of comparison and range check.

That being said:

> Well, the only effect going through GDB values to perform the
> comparison has is to do the appropriate type promotions.  However, if
> this doesn't actually apply for Ada, I'm wondering why we don't simply
> do the comparison on integral LONGEST values directly, like in the
> patch below?

The only problem that I see is when the base type of the range type
is unsigned.  value_less is supposed to be able to handle such cases,
whereas converting the bounds to a LONGEST might cause some problems,
no?

-- 
Joel


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