Christian Smith wrote:
Yes, of course, Windows sticks it's oar in again. Going back to the
previous DLL discussion, this alone is surely confirmation of why the
Windows DLL system sucks.
This really has nothing to do with the Windows DLL system. It is simply
the case that the main application and the SQLite library may be
compiled with different compilers that use different runtime libraries
and therefore implement different memory heaps. You can't in general
expect memory that was allocated from one heap by one runtime library
(used by SQLite) to be correctly released to another heap maintained by
a another runtime library used by the application.
Under *nix it is more common, but not required, for applications to link
to one common runtime library.
For reference (well, for my reference at least) I believe that
returned memory should be considered static to the database
connection, with subsequent invocations overwriting the previous
contents. That way, all management would be internal to the API, and
if the client wants a copy, he should copy it before the next
invocation. This is especially true of such things as error strings.
Ack! No! This leads to non-reentrant code. This is the kind of problem
that the standard asctime() API has. It is much better for the caller to
provide the memory buffer, or have the library dynamically allocate the
buffer and pass it back to the caller. In this case you never have to
worry about some other thread calling the function before your thread
has completed its copy.
Dennis Cote
