-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/11/2010 06:18 AM, Richard Hipp wrote:
>> All the other SQLite interfaces with destructors
>> (sqlite3_create_module_v2(), sqlite3_bind_text(), sqlite3_bind_blob(),
>> sqlite3_result_text(), sqlite3_result_blob()) also invoke their destructors
>> immediately when they fail. Why is that undesirable?
It is very unexpected. Conceptually the API calls involve handing over
something to SQLite to manage, with xDestroy being called when SQLite is
done with it. However if the call to hand over the item fails then SQLite
has not accepted what was handed over. (I use SQLITE_TRANSIENT for all of
those except create module so the destructor issue doesn't apply for them.)
It also prevents one strategy for handling problems. Instead of checking
what is being handed over is okay in advance, you call the function to hand
over and if it gives an error then you try to fix the issue and try handing
it over again. As a (very) contrived example rather than trying to check in
advance that the function name is an acceptable length, I could hand it over
as is, then get an error, then truncate the function name and try again.
>> Except: sqlite3_create_collation_v2() does *not* invoke its destructor when
>> it fails. We are thinking that is a bug and are inclined to fix it. Is
>> changing sqlite3_create_collation_v2() to invoke its destructor when it
>> fails going to cause problems?
It breaks binary compatibility. However in practise I don't think many
people actually call the function. I did a Google Code search and found
zillions of projects having their own copy of sqlite3.{c,h} and sometimes
the test suite, but very few users of the api,
The most notable is Lua who don't even look at the return code!
Consequently they would currently leak memory on sqlite3_create_collation_v2
having an error.
In the Android source I did find sqlite3_create_collation_v2 being called
and it does check the error code, but it too would leak if the destructor
was not called on failure.
What that means is that fixing this will improve things for all the
developers who were lax in not even bothering to check return codes, or did
not have a test suite that caused an error and verified that they cleaned up
properly.
And for those who do check and do clean up properly (so far it looks like it
is just me with that halo :-) ) then fixing this will cause a double free
and hence program crash when SQLite is dynamically linked.
>> Everybody agrees that this needs better documentation. We'll be fixing that
>> too, once we determine what ought to be happening.
It would be nice if each API call had documentation as a separate section on
the various ways it fails, error codes and any side effects.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyzKf4ACgkQmOOfHg372QRqwwCeJ0bTJotF27/JnvCCCmAMZlmX
sPcAn01LyBvUqVImexZ6CC/bv608BvMh
=4aJc
-----END PGP SIGNATURE-----
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
