[EMAIL PROTECTED] uttered:
Two SQLite APIs, sqlite3_exec() and sqlite3_mprintf(), return
strings in memory obtained from a malloc-like memory allocator.
The documentation has always said that you need to use sqlite3_free()
in order to free those strings. But, as it happens, it has
until now worked to call plain old free().
But that might change. In the latest code in CVS, if you
disregard the documentation and use free() in place of
sqlite3_free(), it will likely lead to a segfault. It
might still work depending on how you compile. But a
segfault is the more likely outcome.
So correct code should continue to work fine. But broken
code that happened to work before might now really break.
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.
While it's too late to change now, this puts the client in the unenviable
position of needed to copy the string anyway if the string is required
elsewhere in the client that may not be aware of the special SQLite API
requirements.
I'm hoping that this change will not have too much adverse
impact. If you think this change might cause excessive
hardship, please let me know (before the next release!) and
we will consider using (suboptimal) alternatives that allow
the older broken code to continue functioning. If I do not
hear a sufficiently large outcry, the new code will appear
in the next release.
How is free() sub-optimal? IMHO, malloc/free is not something an API
should be trying to optimise other than internally and opaquely to the
API client. You want to block allocate buffers? Fine, do it in SQLite, but
exporting this to the API is the implementation showing through.
If the client wants to do memory checking, then the developer should link
against instrumented malloc/free like valgrind or ElectricFence.
As to the actual change, I guess this is trying to optimise the realloc
case in the future, perhaps? Is this truly a bottleneck? Otherwise, the
current CVS implementation doesn't add anything.
If this seems like a rant, I'm sorry. I just hate the practice of
overriding malloc/free because it makes API specific a generic case.
Memory allocation is something the original C standard library got mostly
right.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
