Hi, all
CBFalconer wrote:
Toby Ewing wrote:
[...]
In the end the problem wasn't in the list work at all. Way earlier in the program, I'd allocated memory for an array [1..x], then accessed it as [0..x]. On freeing the memory, I guess something funny was set up in the memory manager that came back to bite me way later.
[...]
Glad to hear it. Now I won't do any stewing :-) gpc's lack of runtime range checking bites again :-[ But I'll bet a lot of it was your fault, in failing to declare a suitable index type and then the array as
[...]
Absolutely. This program was the merger of two previous programs that individually worked fine. When I merged them, I failed to check types as carefully as I should have: "We used to think that if we knew one, we knew two, because one and one are two. We are finding that we must learn a great deal more about 'and.'" (Sir Arthur Eddington)
In retrospect, I should have taken a bigger view when stewing over this bug: "hmm, each part worked fine. What about the combination isn't working?" But I got so caught up in where the bug was manifesting itself, that I lost perspective (and several days :-( ). Thanks to all who made suggestions.
CBFalconer wrote:
I maintain that careful declaration of vars and types, using the closest possible limits, pays off in the end.
Also true, and I like to think I usually do this. At least pre-merging!
But for when I don't ;-), and in lieu of a complete range checking implementation, would it be easier to write a stand-alone program parser that would examine a program for potential range-checking errors?
I respect Frank's feeling that range checking is not the most urgent issue for GPC. Range checking is probably an easier issue to debug on one's own than many of the other common bugs, and few of us use GPC for numerical work. I'll take my lumps as a lesson learned on this one.
regards, Toby