> I have no idea how VB6 implements local variables Pure local variables (declared in the actual procedure) are on the stack as well in VB6. VB6 hides all these kind of details, so I never think about this/deal with this.
RBS On Tue, Dec 15, 2015 at 9:33 AM, Hick Gunter <hick at scigames.at> wrote: > >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. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
