Re: [sqlite] Draft docs typo

[Dominique Devienne]

On Mon, Jul 17, 2017 at 5:43 PM, petern  wrote:

> Speaking of type string lifetime, what about pointer lifetime management?
>
> I think you've overlooked the pointer lifetime problem for
> sqlite3_result_pointer(C,P,T).   This form, unlike the blob form, lacks the
> destructor callback for cleanup when SQLite determines the scope of the
> last statement using a copy of the pointer value has exited. Your use case
> appears to presume that a virtual table is managing the pointer object.
> Either that or this mechanism is only otherwise used for global pointer
> variables.   Is there another way for the host application to be notified
> that the last statement using the pointer value has exited scope?


FWIW, I had exactly the same thought. W/o a destructor, this new feature
seems like
it's missing an essential piece, although I'm not sure I understand this
new feature correctly.

It's just that when I see raw pointers being passed around, with no
"lifetime attached",
reflexes kick in and make me worry about leaks, accesses to "dead"
pointers, etc... --DD

PS: That document would be mighty useful Richard :)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Draft docs typo

[Richard Hipp]

I'm trying to write up a document on the whole sqlite3_bind_pointer()
thing now, that describes its motivation and its limitations.
Hopefully that will clear up the confusion.  I will announce when the
new document goes up and request clearance from petern and kmedcalf
prior to the release.

On 7/17/17, Keith Medcalf  wrote:
>
> On Monday, 17 July, 2017 08:00, Richard Hipp  wrote:
>> On 7/17/17, Keith Medcalf  wrote:
>
>> > Also, a question.  sqlite3_bind_pointer(C, P, T) and
>> > sqlite3_value_pointer(C, P, T) indicates that T should be a "static
>> > string".
>
>> > Does this mean of type SQLITE_STATIC and that it cannot be a string
>> > located on the stack (ie, an SQLITE_TRANSIENT), or is a copy made of
>> > the string value (ala SQLITE_TRANSIENT) for future use?
>
>> No copy is made of the string.  SQLite merely keeps a pointer.  If the
>> memory that holds the string is deallocated or reused for some other
>> purpose, bad things will happen.
>
> Ok, understand.  I presume therefore that this is NOT a database type but is
> for passing around value types and contexts only.  Therefore using a
> quoted-string will point to something in the global string table built by
> the compiler and therefore be static.  Makes sense.
>
> So if the sqlite3_bind_pointer is used to bind into a database column, that
> value will be null when stored in the database?  I suppose I could just try
> this, but I thought I would ask you just to be sure ...
>
> Example:
>
> prepare("insert into table (col1, col2) values (?,?)")
> bind_int64(...,1,intval)
> bind_pointer(...,2,, "carray")
> step()
>
> that col1 gets the integer and col2 gets a NULL?  and that the bind_pointer
> actual pointer value and type string is only accessible when the bound
> column is accessed by something that uses the used the sqlite3_value type
> interfaces (that does not actually originate or terminate as a database row
> -- and the pointer type is not preserved in the database itself but would be
> persisted as if NULL?)
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
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

Re: [sqlite] Draft docs typo

[Keith Medcalf]

On Monday, 17 July, 2017 08:00, Richard Hipp  wrote:
> On 7/17/17, Keith Medcalf  wrote:

> > Also, a question.  sqlite3_bind_pointer(C, P, T) and
> > sqlite3_value_pointer(C, P, T) indicates that T should be a "static
> > string".

> > Does this mean of type SQLITE_STATIC and that it cannot be a string
> > located on the stack (ie, an SQLITE_TRANSIENT), or is a copy made of
> > the string value (ala SQLITE_TRANSIENT) for future use?
 
> No copy is made of the string.  SQLite merely keeps a pointer.  If the
> memory that holds the string is deallocated or reused for some other
> purpose, bad things will happen.

Ok, understand.  I presume therefore that this is NOT a database type but is 
for passing around value types and contexts only.  Therefore using a 
quoted-string will point to something in the global string table built by the 
compiler and therefore be static.  Makes sense.

So if the sqlite3_bind_pointer is used to bind into a database column, that 
value will be null when stored in the database?  I suppose I could just try 
this, but I thought I would ask you just to be sure ...

Example:

prepare("insert into table (col1, col2) values (?,?)")
bind_int64(...,1,intval)
bind_pointer(...,2,, "carray")
step()

that col1 gets the integer and col2 gets a NULL?  and that the bind_pointer 
actual pointer value and type string is only accessible when the bound column 
is accessed by something that uses the used the sqlite3_value type interfaces 
(that does not actually originate or terminate as a database row -- and the 
pointer type is not preserved in the database itself but would be persisted as 
if NULL?)




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Draft docs typo

[petern]

Speaking of type string lifetime, what about pointer lifetime management?

I think you've overlooked the pointer lifetime problem for
sqlite3_result_pointer(C,P,T).   This form, unlike the blob form, lacks the
destructor callback for cleanup when SQLite determines the scope of the
last statement using a copy of the pointer value has exited. Your use case
appears to presume that a virtual table is managing the pointer object.
Either that or this mechanism is only otherwise used for global pointer
variables.   Is there another way for the host application to be notified
that the last statement using the pointer value has exited scope?



On Mon, Jul 17, 2017 at 6:59 AM, Richard Hipp  wrote:

> On 7/17/17, Keith Medcalf  wrote:
> >
> > Also, a question.  sqlite3_bind_pointer(C, P, T) and
> > sqlite3_value_pointer(C, P, T) indicates that T should be a "static
> string".
> >  Does this mean of type SQLITE_STATIC and that it cannot be a string
> located
> > on the stack (ie, an SQLITE_TRANSIENT), or is a copy made of the string
> > value (ala SQLITE_TRANSIENT) for future use?
>
> No copy is made of the string.  SQLite merely keeps a pointer.  If the
> memory that holds the string is deallocated or reused for some other
> purpose, bad things will happen.
>
> >
> > ---
> > Life should not be a journey to the grave with the intention of arriving
> > safely in a pretty and well preserved body, but rather to skid in
> broadside
> > in a cloud of smoke, thoroughly used up, totally worn out, and loudly
> > proclaiming "Wow! What a Ride!"
> >  -- Hunter S. Thompson
> >
> >
> >
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
>
>
> --
> 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

Re: [sqlite] Draft docs typo

[Richard Hipp]

On 7/17/17, Keith Medcalf  wrote:
>
> Also, a question.  sqlite3_bind_pointer(C, P, T) and
> sqlite3_value_pointer(C, P, T) indicates that T should be a "static string".
>  Does this mean of type SQLITE_STATIC and that it cannot be a string located
> on the stack (ie, an SQLITE_TRANSIENT), or is a copy made of the string
> value (ala SQLITE_TRANSIENT) for future use?

No copy is made of the string.  SQLite merely keeps a pointer.  If the
memory that holds the string is deallocated or reused for some other
purpose, bad things will happen.

>
> ---
> Life should not be a journey to the grave with the intention of arriving
> safely in a pretty and well preserved body, but rather to skid in broadside
> in a cloud of smoke, thoroughly used up, totally worn out, and loudly
> proclaiming "Wow! What a Ride!"
>  -- Hunter S. Thompson
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
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