On Thu, Aug 03, 2017 at 08:33:31PM +0200, Ulrich Telle wrote: > > Rhetorical: Why not use the pointer value itself then instead of the > > contents of the string? After all, the string should just be a .text > > section constant string... > > The SQLite developer team chose a string representation for the > pointer type to make naming collisions less likely.
So, that was rhetorical :) > > Now, suppose that you're building FFI bindings for SQLite3 for some > > programming language, e.g., Python. So you have a string from the > > run-time for this language, but you can't ensure that it will have the > > necessary lifetime. So now you have to make a copy. It's a bit of a > > pain. SQLite3 could have made a copy itself. > > I would have preferred that, too, but I learned that this would have > imposed a runtime penalty even for applications not using the new > pointer interface. That seems unlikely. Basically the connection has to have an array/list of types, which can be empty/null when the pointer passing interface is not used. > > On the flip side, it's possible that you have to do some conversions > > anyways because SQLite3 deals with C strings and the target language > > run-time deals with counted-codeunit strings or whatever. > > The conversion is not the problem. The problem is that SQLite requires > that the pointer type string has a life span at least as long as the > prepared statement referring to it. And this requires that the > application takes care of that. I meant that the author of some bindings for SQLite3 might have to perform conversions at their layer. If you have to do that, then allocating your own copy (and keeping track of it so you can release it atexit() or whatever) is not that big a deal, which is why I concluded with this: > > So even if SQLite3 made a copy, the FFI bindings might have to make > > their own copy anyways. Thus: who cares :) > > The problem is to keep the copy alive long enough. However, the > problem is not that big. It can be solved in less than 50 lines of > code. It's easier for SQLite3 to do that since it has a suitable structure for that: the connection associated with the statement. Whereas for an FFI bindings of SQLite3 it can be much harder, since now you'll need a list/table of these strings to free atexit() or when the DLL is unloded, or whatever is appropriate. > > Still, for many cases it will be easier to write code to this API if > > SQLite3 makes its own copy. > > Yes, but Richard Hipp made it quite clear that the latter is unlikely > to happen. Maybe I've made a strong enough argument that he might revisit that decision. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
