> The only useful reason I could see for this change is handling nulls in names
To me the reason to make a change at all, and I grant you it ain't broke, is to get rid of all those warning messages. In the linux kernel they encourage you to make such changes, even in working code, and it's surprising how you can compile the kernel, zillions of lines of code, and how few warnings there are. In contrast js 24 gives pages and pages of warnings, so that you can't tell if any of them should be taken seriously. In that sense Chris' original patch does the trick, and I'm ok with that. I just thought it might not be much more work to put the struct right in the list, rather than struct * with manual allocs. And maybe clean up the code a bit. Guess that's Chris' call. As for line count, I may be able to push from 10 million to 100 million, but probably not more than that because of the way files are represented with arrays inside, having 4 byte indexes etc. There is another factor wherein you can run out of your 10 million lines not because they are really being used, but because there is no garbage collector for lines. Make a substitution, and of course you have the new line, but I have to keep the old one in case of an undo. Make another change and I suppose I could get rid of that original line, and yes it is freed (no memory leak), but the index inside is not reclaimed. The indexes march on towards 10 million. So after a long edbrowse session you could run into this, even though you don't have 10 million lines active now. I've been meaning to address this in some fashion for, or er um, at least a decade. Well probably push the limit to 100 million first, that's more important and easier, then think about better gc procedures for the line indexes. I have played with jsrt for a while but haven't been able to produce your seg fault. And the one that I had earlier, reproducible, went away with js 24. I'll keep fishing around to see if I can trip another one. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
