Dominique, > I think on the contrary they are more meant to communicate across different > UDFs of the *same* extension, and not across extensions.
You are most probably right. It seems very unlikely that unrelated extensions would exchange pointers. However, mainly the new interface will be used to communicate between the aplication and a SQLite extension. AFAIK one of the main reasons for the new interface was to prevent pointer maniulation via pure SQL (what was possible in older SQLite versions). With the new interface this is no longer possible. Instead, an attacker would need to inject a malicious extension - a lot more difficult than just executing some pure SQL statements. > I'm not even sure you can guarantee uniqueness of string literals across > dynamically loaded shared libraries, maybe the runtime linker > merges equivalent read-only "static" text from different libs, but that > seems very platform-dependent and not something to rely on. The string literals used for the pointer types don't have to be unique instances. It is sufficient that their content is identical. Not the string pointer is checked, but the string content. > When you look at it from this lens, then enforcing string literals for the > type-pointer makes sense. My $0.02, FWIW. --DD It's a design decision we will have to live with. I understand the reasoning behind the decision, but as I pointed out it is a low hurdle and does not prevent misuse, it just makes it slightly less likely to happen. > PS: Yes, like others I'd love it if DRH went further into this "custom > type" route, even persistent ones longer term with a format change, > since pointer-binding with type-string-pointer is going in that > direction, at least at runtime-only, and only for "temporaries" across UDFs, > but I'm afraid we're a long way from that, and I'm not holding my breadth > :) I don't believe that extensions of SQLite in this direction are to be expected in the near future. Regards, Ulrich _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
