If you’re concerned about people faking pointers, you could always go with something like “org.sqlite.fts3.01Yzg5x.snippet”.
But given this design, you need to have already injected a C extension to even access the pointers, so I’m not sure what the issue is. On 7/24/17, 9:19 AM, "sqlite-users on behalf of Hick Gunter" <[email protected] on behalf of [email protected]> wrote: Naming conventions (if strictly adhered to) are moderately good at avoiding conflicts, but take the guesswork out of "faking a pointer". It also assumes that pointers for "whatever" are interchangeable between different queries in a process, i.e. passing a "whatever" pointer from statement A to a function in statement B does not pose a risk. -----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:[email protected]] Im Auftrag von Peter Da Silva Gesendet: Montag, 24. Juli 2017 15:37 An: SQLite mailing list <[email protected]> Betreff: Re: [sqlite] New draft document on the new pointer-passing interfaces What about imposing some structure on the pointer type strings that uses a guaranteed unique substring, for example “org.sqlite.fts3.snippet”, to ensure there wouldn’t be accidental conflicts? On 7/24/17, 6:54 AM, "sqlite-users on behalf of Richard Hipp" <[email protected] on behalf of [email protected]> wrote: https://www.sqlite.org/draft/bindptr.html -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: [email protected] This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
