On Friday, 21 July, 2017 10:51, Richard Hipp <d...@sqlite.org> wrote:
> But sqlite3_result_pointer() and sqlite3_bind_pointer() are not > invoked from those languages. The _pointer() routines are invoked > from C, and C does easily support string literals that are static > strings. > A C-language wrapper around sqlite3_result_pointer() and > sqlite3_bind_pointer() that interfaces to the non-static-string > language can simply insert the required static string. Well, yes. Technically. Almost everything everywhere is called from code written in C. Very little meaningful anything is written in any other language. So although you may be writing something in Java (heavens forbid), Java was written in C. So in the end, all calls are made from software written in C. This is the way of the world. Some people just like to add lots of syntactical sugar and overhead which eventually ends up being C code -- either translated by a preprocessor (as in the case of C++), or by a compiler written in C (or written in some other language that was written in C ... repeat for as deep down the rabbit hole as you need to go). There are a few self-hosted language compilers that are exceptions, but not very many. And they all started as C before they were re-written in themself so they could become self-hosted. However, the change does create a problem when one is using a sugary language (for example Python). It does not know how to bind pointers, nor is there any way to pass in a variable static "string" as an extra parameter. So for example, the carray extension *used* to be able to be passed a pointer which was bound as an int (you obtain the pointer by allocating a ctypes array and asking for the pointer) -- of course this is unsafe if you do something stupid -- but then almost everything including making a nice cuppa tea is unsafe if you do something stupid. I have fiddled with defining a new type for the python interface that can contain a string and a reference to a ctypes object (so that the string stays in scope and the ctypes array stays in scope as long as the outer object stays in scope), and then adding an addition bind detection for this type of object. It works but it is far more complicated than just modifying the carray extension so that it will accept integers for the pointer (as well as pointer types). Plus of course (sending an integer) works with all interfaces that can get a pointer rather than having to update every single possible sugary extension. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
