Indeed.  Or Type(T) of long, or sqlite_int64, or whatever is most universal
where porting other architectures is concerned. It would be a shame if the
API had to be changed later because the integer type chosen couldn't hold a
pointer.

From there, in a closed compiled host C/C++ setting with the discipline of
header files, one may simply perform the stricmp("CARRAY",(const char*) T)
cast to T string pointer comparison as desired and leave the API out of
that part.  This leaves open the more conventional test of T with enum or
#define compile time constant.

Now it remains, on the surface, that this new pseudo null pointer API
appears redundant in light of the existing BLOB interface and the
possibility of simply adding Type(T) versions of those BLOB function
signatures to the API.

How was adding to the BLOB API ruled out?  Is there a fundamental problem
with slightly broadening the BLOB API to deal with typed host objects?
Surely returning zero for the Type(T) would be backward compatible, would
it not?  Just asking.









On Fri, Jul 21, 2017 at 12:48 PM, Keith Medcalf <kmedc...@dessus.com> wrote:

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

Reply via email to