On Thu, Aug 03, 2017 at 12:33:05PM +0300, Paul wrote: > To me it seems like that string is very tightly coupled with the > actual pointer being bound. I think it's a good idea, in case you > cannot make it a literal or static, to keep it with an object whose > pointer you bind.
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... 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. 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. So even if SQLite3 made a copy, the FFI bindings might have to make their own copy anyways. Thus: who cares :) Still, for many cases it will be easier to write code to this API if SQLite3 makes its own copy. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
