Gwendal, > I agree that it's impossible to enforce "static strings" or "strings that > live long enough" with the C/C++ type system. > > You chose to force key management down the throat of your users,
Hm, quite a tough expression ... the advantage is that the wrapper does not depend on the pointer type being a string literal or static string. For the purpose - to allow pointer binding to communicate with existing SQLite extension - I think this is a legitimate approach. Regarding the development of SQLite extensions (UDFs) and using the pointer-binding interface to communicate between different extensions (AFAIK one of the reasons to introduce the new pointer-binding interface) the advice to use string literals is certainly good. Although my wrapper allows to implement UDFs, it is not meant (and not well suited) to implement stand-alone SQLite extensions. It is meant for end-user applications where the developer has access to all information, database related or not, anyway. > with two problems : > > - All the potential memory leaks, thread races, etc that may occur if your > key management has subtle concurrency bugs. Using the same prepared statement object in different threads isn't a good idea anyway ... if it works at all. If the application is carefully designed in respect to SQLite database access I don't see a high risk. > - Making your users think they can build *stuff* on top of this API, *stuff* > that are explicitly > out of scope of the pointer API as described by the design rationale of > SQLite pointers API. Sorry, since SQLite has no means to absolutely enforce the use of string literals for the pointer type parameter, developers can build *stuff* on top of the pointer-binding interface anyway. According to the explanation from Richard Hipp a main reason for the design decision was to avoid a runtime penalty for applications not using the pointer-binding interface at all. > Plus memory problems if your users think they can feed your API with > arbitrary strings built at runtime. My "users" are software developers. Why should they want to feed the API with arbitrary strings built at runtime? I'm pretty sure that in most cases the type strings will be string literals, but the API will not fail if a string variable is used. > I think the problem, assuming there is one, is not in the SQLite API. I ran into the problem that the pointer type string I tried to bind to the new interface was a temporary object. And that doesn't work with the current SQLite API. I learned that the new SQLite pointer-binding API was designed as it is on purpose. I resolved the issue for my wrapper classes. And that's it. If a malicious developer wants to do evil, he can do so even with the SQLite API directly. He doesn't need my wrapper for that. Regards, Ulrich _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
