Dennis Cote uttered:
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.
Under UNIX it is more common because UNIX provides a runtime system by
default. Windows programs all ship with their own runtime due to sloppy
engineering on MS's part. It harks back to the days when each DLL had it's
own local data segment under Win16. Implementation details from 20 years
ago biting us in the bum even when the Win32 API doesn't have segments!
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.
Static is probably the wrong word. The string is local to the database
connection, which shouldn't be used by more than one thread without proper
synchronisation.
Anyway, it's not difficult to provide thread local storage. HP-UX's
netdb.h functions (gethostbyname etc.) are fully re-entrant despite
returning 'static' data, for example. Other UNIXs got hamstrung with
various getXbyY_r implementations, with horrible semantics.
Dennis Cote
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
