[GRASS-dev] vector large file support

[Glynn Clements]

Markus Metz wrote:

> >> I understand the concept of RTrees better than this code, but I suspect 
> >> that at line 119, line number is used as memory address for a pointer 
> >> and at line 285, the memory address of a pointer is used as line number. 
> >> Can you developer cracks confirm that?
> >>     
> >
> > ISTR something like that. This isn't necessarily a problem, so long
> > as:
> >
> > 1. The field is wide enough to hold both types.
> > 2. The code doesn't attempt to read an integer when a pointer was
> > stored, and vice versa.
> 
> That thing branch[i].child is a pointer to the next node in the tree, if 
> I understand the code correctly.

It's either a pointer to the child or, at the lowest level (where
there are no children), an integer ("tid").

> This is a standard tree design, not 
> only of RTrees, but of many search trees. So your condition #2 would be 
> violated, because a pointer is passed as an integer to RTreeInsertRect().

Not if the "pointer" is actually an integer which was stuffed into the
field, which is exactly what index.c:119 does:

	b.child = (struct Node *)tid;

> I believe the compile warning was there for a reason.

The compiler complains because, on a 64-bit architecture, casting a
pointer to an "int" results in truncation. The compiler has no way of
knowing whether the "pointer" is just an integer which was stuffed
into the field.

If the code used a union of an int and a "struct Node *", instead of
just a "struct Node *", the resulting machine code would be identical,
but the compiler wouldn't complain because the code would "explain
itself" to the compiler's satisfaction.

-- 
Glynn Clements <glynn at gclements.plus.com>