Great. But, if this is an ultimate replacement for BLOB'ed pointers, these new pseudo-null pointers must support SQLITE_STATIC and destructor function pointer lifetime disposition for those migrating their code.
Why can't the producer destructor disposition be preserved within a chain of application functions by subsequent consumers passing SQLITE_STATIC disposition as they do now? Isn't this feature just an accident of statement scope controlled destruction that will continue to work with tracked lifetime pseudo-null pointers? BTW, let's call them what they are. These are explicit pseudo-nulls for the purpose of keeping pointer bits out of band from hacker SQL. Also. What is to stop black budget funded developers from creating popular applications in the wild which preserve penetration channels of BLOB pointers the original way? Total security improvement justifications for the pseudo-null pointer API are specious if the API is merely another alternative. Are sqlite3_result_subtype() and sqlite3_value_subtype() being deprecated in light of the duplicate functionality? Supplementing/deprecating the already secure sqlite3_X_subtype() API with a more complete and pointer leak opaque replacement sqlite3_X_pointer() API seems a worthy goal. But, if that's the plan, where is the rest to the proposal? Honestly, it appears all you've proposed so far is yet another way to pass pointers more aligned with the whims of your present tastes for FTS3 MATCH, FTS5 extensions, and one code sample. To those posting low information congratulatory notes on this thread, you'd better hold off on popping those champagne corks. The current API already contains irreversible additions to solve this problem that fell short. On Mon, Jul 24, 2017 at 4:54 AM, Richard Hipp <d...@sqlite.org> wrote: > https://www.sqlite.org/draft/bindptr.html > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
