Re: [sqlite] Problem with the new pointer-passing interface

Dominique. strcmp alone won't care if zPType is code segment or data segment. As is, this release won't need the dynamic linker to perfectly consolidate constants. Much ado. [You are also free to clone three very tiny API functions substituting integer/etc PType if you're in the mood to ship a

Re: [sqlite] Problem with the new pointer-passing interface

Dominique, > I think on the contrary they are more meant to communicate across different > UDFs of the *same* extension, and not across extensions. You are most probably right. It seems very unlikely that unrelated extensions would exchange pointers. However, mainly the new interface will be use

Re: [sqlite] Problem with the new pointer-passing interface

On Fri, Aug 4, 2017 at 11:37 AM, Ulrich Telle wrote: > Regarding the development of SQLite extensions (UDFs) and using the > pointer-binding interface to communicate between different extensions (AFAIK one of the reasons to introduce the new pointer-binding interface) > the advice to use string

Re: [sqlite] Problem with the new pointer-passing interface

Gwendal, > I agree that it's impossible to enforce "static strings" or "strings that > live long enough" with the C/C++ type system. > > You chose to force key management down the throat of your users, Hm, quite a tough expression ... the advantage is that the wrapper does not depend on the po

Re: [sqlite] Problem with the new pointer-passing interface

I agree that it's impossible to enforce "static strings" or "strings that live long enough" with the C/C++ type system. You chose to force key management down the throat of your users, with two problems : - All the potential memory leaks, thread races, etc that may occur if your key management

Re: [sqlite] Problem with the new pointer-passing interface

Gwendal, > But... why don't you simply ask your users for a static string as well??? > C++ makes it trivial to support this requirement of the C API. I could do that, of course. But it wouldn't solve the issue. It would push the problem just one level up. > // pointerType should be a static str

Re: [sqlite] Problem with the new pointer-passing interface

But... why don't you simply ask your users for a static string as well??? C++ makes it trivial to support this requirement of the C API. // pointerType should be a static string void wxSQLite3Statement::Bind(int paramIndex, void* pointer, char *pointerType, void(*DeletePointer)(v

Re: [sqlite] Problem with the new pointer-passing interface

On Thu, Aug 03, 2017 at 08:33:31PM +0200, Ulrich Telle wrote: > > 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... > > The SQLite developer team chose a string representatio

Re: [sqlite] Problem with the new pointer-passing interface

Nico, > 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... The SQLite developer team chose a string representation for the pointer type to make naming collisions less likely. >

Re: [sqlite] Problem with the new pointer-passing interface

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 no

Re: [sqlite] Problem with the new pointer-passing interface

Richard, > Can you please provide more details on how having a dynamic string for > the pointer type would be helpful? What is it that you are trying to > do that string constant will not work? Please be as specific as > possible, so that I might better understand your problem. I maintain a C++

Re: [sqlite] Problem with the new pointer-passing interface

Richard, > On 8/3/17, Ulrich Telle wrote: > > > > The description of the new pointer-passing interface gives the impression > > that restricting the pointer type parameter to static strings or literals > > prevents misuse of the new feature. And that is definitely not the case. It > > might be a

Re: [sqlite] Problem with the new pointer-passing interface

Peter, > On 8/3/17, 9:16 AM, "sqlite-users on behalf of Ulrich Telle"wrote: > > The description of the new pointer-passing interface gives the > > impression that restricting the pointer type parameter to static > > strings or literals prevents misuse of the new feature. > > The term I used was “

Re: [sqlite] Problem with the new pointer-passing interface

On 8/3/17, Ulrich Telle wrote: > > Right. And therefore I think that the restriction to static strings or > literals for the pointer type parameter just makes life a bit harder for > honest developers of wrappers or the like, but prevents nothing. > Can you please provide more details on how havi

Re: [sqlite] Problem with the new pointer-passing interface

On 8/3/17, Ulrich Telle wrote: > > The description of the new pointer-passing interface gives the impression > that restricting the pointer type parameter to static strings or literals > prevents misuse of the new feature. And that is definitely not the case. It > might be a hurdle for unsophistic

Re: [sqlite] Problem with the new pointer-passing interface

On 8/3/17, 9:16 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > The description of the new pointer-passing interface gives the impression > that restricting the pointer type parameter to static strings or literals > prevents misuse of the new feature. The term I used was “deters”. > An

Re: [sqlite] Problem with the new pointer-passing interface

Peter, > On 8/3/17, 8:56 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > > Nevertheless, I think the pointer type string restriction gives a false > > sense of security. > > You described creating a malicious extension that would give you the ability > to probe pointers by forging strings

Re: [sqlite] Problem with the new pointer-passing interface

On 8/3/17, 8:56 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > Nevertheless, I think the pointer type string restriction gives a false sense > of security. You described creating a malicious extension that would give you the ability to probe pointers by forging strings. From a securit

Re: [sqlite] Problem with the new pointer-passing interface

Peter, > On 8/3/17, 8:27 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > > I really don't think that the latter is true. To overcome the restriction > > is extremly simple, if you don't care about memory leaks. Just do [...] > > If you’re creating a malicious extension, sure. But if you’re

Re: [sqlite] Problem with the new pointer-passing interface

Richard, > As the desire for dynamic pointer type strings seems to be a recurring > theme, I have added lots of extra documentation that attempts to > explain why the pointer-passing interfaces deliberately use a constant > static string for the pointer type: > >https://sqlite.org/bindptr.htm

Re: [sqlite] Problem with the new pointer-passing interface

> Le 3 août 2017 à 15:27, Ulrich Telle a écrit : > > Thanks for the pointer. I have to admit that I referred to > http://sqlite.org/c3ref/bind_blob.html > . No offense :-) The SQLite documentation has organically grown, and information is often scatter

Re: [sqlite] Problem with the new pointer-passing interface

On 8/3/17, 8:27 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > I really don't think that the latter is true. To overcome the restriction is > extremly simple, if you don't care about memory leaks. Just do [...] If you’re creating a malicious extension, sure. But if you’re creating an e

Re: [sqlite] Problem with the new pointer-passing interface

Gwendal, > > Le 3 août 2017 à 14:27, Peter Da Silva a > > écrit : > > > > On 8/3/17, 4:22 AM, "sqlite-users on behalf of Ulrich Telle" > > > ulrich.te...@gmx.de> wrote: > >> IMHO it would be better if the function sqlite3_bind_pointer would make a > >> copy of the type string and would thus

Re: [sqlite] Problem with the new pointer-passing interface

As the desire for dynamic pointer type strings seems to be a recurring theme, I have added lots of extra documentation that attempts to explain why the pointer-passing interfaces deliberately use a constant static string for the pointer type: https://sqlite.org/bindptr.html#ptrtyp -- D. Richa

Re: [sqlite] Problem with the new pointer-passing interface

Peter, > On 8/3/17, 4:22 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > > IMHO it would be better if the function sqlite3_bind_pointer would make a > > copy of the type string > > and would thus be independent of the life span of the type parameter. > > I believe that this was a deliberat

Re: [sqlite] Problem with the new pointer-passing interface

> Le 3 août 2017 à 14:27, Peter Da Silva a > écrit : > > On 8/3/17, 4:22 AM, "sqlite-users on behalf of Ulrich Telle" > ulrich.te...@gmx.de> wrote: >> IMHO it would be better if the function sqlite3_bind_pointer would make a >> copy of the type string and would thus be independent of the lif

Re: [sqlite] Problem with the new pointer-passing interface

On 8/3/17, 4:22 AM, "sqlite-users on behalf of Ulrich Telle" wrote: > IMHO it would be better if the function sqlite3_bind_pointer would make a > copy of the type string and would thus be independent of the life span of the > type parameter. I believe that this was a deliberate choice to dete

Re: [sqlite] Problem with the new pointer-passing interface

Hi Paul, > To me it seems like that string is very tightly coupled with the actual > pointer being bound. No, not really. The type string is tightly coupled with the extension module which uses the pointer. The type string allows the extension module to check whether the pointer is really mean

Re: [sqlite] Problem with the new pointer-passing interface

Hi Clemens, > Ulrich Telle wrote: > > In the comment of the sqlite3_bind_pointer() routine I found this note: > > > > The T parameter should be a static string, preferably a string literal. > > > > In my case this is quite cumbersome, since in my wrapper I have to extract > > the value of paramete

Re: [sqlite] Problem with the new pointer-passing interface

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. > > Hi, > > I came across a problem with the new pointer-passing interface

[sqlite] Problem with the new pointer-passing interface

Hi, I came across a problem with the new pointer-passing interface, when I tried to incorporate the carray extension into my wxSQLite3 wrapper for SQLite3. In the comment of the sqlite3_bind_pointer() routine I found this note: The T parameter should be a static string, preferably a string l

Re: [sqlite] Problem with the new pointer-passing interface

Ulrich Telle wrote: > In the comment of the sqlite3_bind_pointer() routine I found this note: > > The T parameter should be a static string, preferably a string literal. > > In my case this is quite cumbersome, since in my wrapper I have to extract > the value of parameter T from a temporary string

[sqlite] Problem with the new pointer-passing interface

Hi, I came across a problem with the new pointer-passing interface, when I tried to incorporate the carray extension into my wxSQLite3 wrapper for SQLite3. In the comment of the sqlite3_bind_pointer() routine I found this note: The T parameter should be a static string, preferably a strin