Glynn Clements wrote:
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.
That thing branch[i].child is a pointer to the next node in the tree, if
I understand the code correctly. 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(). I believe the compile warning was there for a reason.
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.
In my patch I am using two more fields in the branch structure and thus
expected higher memory consumption, but for some unknown reason I end up
with fewer internal nodes, which in turn means that memory consumption
is lower and vector processing faster. I'm not complaining as long as
everything works as before, now without segfault :-)
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.
OK, I want to test a bit more and have a closer look at the spatial
index dumps. If I can't find crucial differences I will commit to trunk.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
