Re: [unavailable values part 1, 03/17] expose list of available ranges to common code

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 15 February 2011 21:12:23, Jan Kratochvil wrote:
> On Mon, 14 Feb 2011 20:39:10 +0100, Pedro Alves wrote:
> > On Monday 14 February 2011 11:59:39, Jan Kratochvil wrote:
> > > > +struct mem_range
> > > > +{
> > > > +  /* Lowest address in the range.  */
> > > > +  CORE_ADDR start;
> > > > +
> > > > +  /* Length of the range.  */
> > > > +  int length;
> > > > +};
> > > 
> > > Why couldn't GDB become 64bit clean - that is CORE_ADDR length.  
> > 
> > Probably a leftover from the value ranges stuff (value lengths
> > are ints, and so I made the value range lengths be ints too).
> > But I disagree with making it a CORE_ADDR.  I think
> > lengths should be LONGEST or ULONGEST.
> 
> While ULONGEST should work due to this invariant:
> 	ULONGEST_MAX >= CORE_ADDR_MAX
> 
> Still in which case an inferior object size does not fit in CORE_ADDR?
> I do not think it can happen, CORE_ADDR should be OK for inferior size_t.

It's (mainly) not about fitting.  An address is fundamently not the same
as a length/size.  Representing a size with a type meant for
addresses is just not right, IMO.  Imagine if CORE_ADDR was a C++ object
that also included a reference to an address space (I'm not saying
it should, only that it could.  Even today you have the ppc/cell
gdb using special bit hacks in CORE_ADDRs to represent address
spaces).  Then it would be clear that using it for lengths/sizes
wasn't right.  Just as size_t should be used for host sizes, and
uintptr_t/intptr_t/pointers for host addresses. The opposite of what you
said is actually quite possible.  There are systems where the addressable
address space is wider than the size of a single object/array can
be (thus size_t bitwidth may be narrower than than of uintptr_t).

As for what type for use then instead of CORE_ADDR, we traditionaly
use LONGEST/ULONGEST throughout, AFAICS.  I guess nobody ever saw
a real need to come up with a special type for it.

OOC, I did:

 $ grep "CORE_ADDR len" *  -rn
 python/py-inferior.c:63:  CORE_ADDR length;

And I'm going to claim that this only hit shouldn't be
using CORE_ADDR.

Grepping for "LONGEST len" actually finds a large number
of uses.

-- 
Pedro Alves