Glynn Clements wrote:
[...]
External callers aren't a problem, as they only ever call
RTreeInsertRect() with level == 0. It's only when RTreeDeleteRect()
uses it to re-insert internal nodes that the truncation can arise.
I'm pretty sure that this caused the segfault.
BTW, external callers also call RTreeDeleteRect() with level == 0 and
RTreeSearch()
My inclination would be to change the "int tid" parameters to
"struct Node *child", and make RTreeInsertRect() a compatibility
wrapper for the benefit of external callers, i.e.:
-static int RTreeInsertRect2(struct Rect *r, int tid, ...
+static int RTreeInsertRect2(struct Rect *r, struct Node *child, ...
-int RTreeInsertRect(struct Rect *R, int Tid, ...
+int RTreeInsertRect1(struct Rect *R, struct Node *child, ...
int RTreeInsertRect(struct Rect *R, int Tid, struct Node **Root, int Level)
{
assert(level == 0);
return RTreeInsertRect1(R, (struct Node *) Tid, Root, Level);
}
same for deletion
-static int RTreeDeleteRect2(struct Rect *r, int tid, ...
+static int RTreeDeleteRect2(struct Rect *r, struct Node *child, ...
-int RTreeDeleteRect(struct Rect *R, int Tid, ...
+int RTreeDeleteRect1(struct Rect *R, struct Node *child, ...
compatibility wrapper:
int RTreeDeleteRect(struct Rect *R, int Tid, struct Node **Root, int Level)
{
assert(level == 0); /* I like that, external callers should never ever
delete an internal rectangle */
return RTreeDeleteRect1(R, (struct Node *) Tid, Root, Level);
}
then replace "(struct Node *)tid" with "child" in RTreeInsertRect2() and
RTreeDeleteRect2()
and replace RTreeInsertRect() with RTreeInsertRect1() in RTreeDeleteRect()
That would be a very elegant solution.
There will still be a compile warning with RTreeSearch() when (struct
Node *) gets truncated to an int on 64bit systems. Since this happens
only on level 0 where an int was stuffed in the pointer, (struct Node *)
should not be larger than INT_MAX. I hope. RTreeSearch() has worked fine
before, so it should still work after these changes.
I don't think the problems go any further than that.
Let's hope so. I go testing now.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
