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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
