[GRASS-dev] vector large file support

[Glynn Clements]

Markus Metz wrote:

> I suspect the bugs in rtree to be in index.c at line 119
> b.child = (struct Node *)tid;
> b.child is a pointer to the next node in the RTree. tid is the line 
> number for which a new bounding box will be inserted in the RTree. This 
> is a cast from integer to pointer, giving a compile time warning.
> and at lines 284 - 286
>             RTreeInsertRect(&(tmp_nptr->branch[i].rect),
>                     (int)tmp_nptr->branch[i].child,      <-- cast from pointer to integer of different size
>                     nn, tmp_nptr->level);
> 
> 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.

Having said that, using a union would be preferable. Using distinct
fields would be more robust (although use slightly more memory), as
that would enable point #2 above to be verified at run-time.

> line 285 was the bug causing the segfault when cleaning large vectors. I 
> gave the RTree Branch structure a new variable, its id, and used the id 
> where appropriate and pointer where appropriate, and got the above 
> described results (also no more compile warnings).
> 
> IMHO stuff like this needs to be sorted out before the vector libs get LFS.
> 
> What should I do now? Submit a patch to trac or commit to trunk or leave 
> it open for discussion?

I suggest committing it. AFAIK, no-one really understands the rtree
code, so I doubt that you'll get much feedback from a patch.

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