[EMAIL PROTECTED] uttered:
Christian Smith <[EMAIL PROTECTED]> wrote:
My own personal opinion on these coding style issues is if the API
requires special handling of cleanup, then the API should do the cleanup.
Returning an allocated string that requires special cleanup results in a
potentially generic operation now being special cased by the API client.
If all the world was Unix, this would work great. But sadly,
it is not. We also have to support windows. See
http://www.sqlite.org/cvstrac/tktview?tn=444
The sqlite_freemem() API is an old SQLite version 2 API that was
added to work around the fact that memory allocated using malloc()
in a DLL cannot be passed to free() in the main program.
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.
My previous rant was really that, just a rant. Given the previous
interface, you must maintain compatibility, and breaking the old use of
free() should be acceptable. My own code is not affected, as I already
used sqlite_freemem (stuck with 2.x for the moment.)
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.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
