Igor,
>Can't you preallocate sufficient memory at the time the collation is >created? Unfornately I can't do that: it would mean I place a maximum size on a work space allocated at creation for manipulating user strings, which is taboo in my view. This is for getting unaccented copies of input strings, which sometimes involves expansion of a single character into 2 to 5 or 6 simpler characters. I use this for offering unaccented collation as well as LIKE, friends and a fuzzy search. Working on "live" strings (without dup) would make the code such a mess (and slow) that it's unreasonable. >It seems to me that, rather than tricking SQLite into crashing, it would >be more straightforward to just call abort(). Well, I might abort the process. If someone gets into the situation of such low memory that I can't malloc or realloc 20 long int (u32) then it's likely there is a much bigger problem elsewhere. OTOH if a fuzzy search is launched on a column containing strings big enough to cause memory suffocation, then it _is_ a big mistake. Committing suicide in such conditions is understandable, even if I don't like it. Really, SQLite doesn't have emergency brakes? _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
