Nico, > 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. > 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. > 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. > 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. > 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. Regards, Ulrich _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
