>Thanks for clarifying that. > >> If the pointer refers to memory obtained from sqlite3_malloc >How do I know that is the case? >My callback procedure (the procedure that does the actual work, altering the >string) is in a VB6 ActiveX dll, so not in sqlite3.dll
If you called an sqlite3 API function that says it allocates memory, like sqlite3_malloc() or sqlite3_mprinft() to produce the string. > >> If the pointer refers to memory obtained from your own allocator >I suppose this is the case if it is a local variable in this callback >procedure in my VB6 dll. >In VB6 local variables will go out of scope (cleaned up) once the procedure is >finished. >So in that case can I use SQLITE_STATIC? I guess NO. SQLite needs the value until at least up to the next call to sqlite3_step(). Calling sqlite3_finalize() or sqlite3_reset() should also "clear" the "current row". > >> In all other cases, pass SQLITE_TRANSIENT and, if necessary, dispose >> of the memory appropriately. >When is it necessary and what is appropriate? You should know where the memory used to store the string in your own code comes from and how to deal with it. As you already stated, a local variable in your callback procedure goes out of scope automatically. I have no idea how VB6 implements local variables; in C they are located on the stack, which may be overwritten by other function calls. On Tue, Dec 15, 2015 at 7:52 AM, Hick Gunter <hick at scigames.at> wrote: >> The rules are quite simple: >> >> If the pointer refers to static memory (preallocated string constants, >> global variables that you can guarantee won't change while SQLite uses >> them) use SQLITE_STATIC >> >> If the pointer refers to memory obtained from sqlite3_malloc (directly >> or indirectly e.g. via sqlite3_mprintf() ) and you won't refer to this >> object again, pass sqlite3_free. >> >> If the pointer refers to memory obtained from your own allocator and >> you won't refer to this object again, pass your own destructor. >> >> In all other cases, pass SQLITE_TRANSIENT and, if necessary, dispose >> of the memory appropriately. >> >> SQLITE_TRANSIENT is safe but slow, because SQLite needs to copy the string. >> Passing a destructor function is faster but implies a contract to NOT >> USE THE POINTER AGAIN yourself. >> SQLITE_STATIC is fastest but implies a contract that the MEMORY WILL >> NOT CHANGE. >> ___________________________________________ 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: hick at scigames.at 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.
