-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/26/2011 09:44 AM, David Garfield wrote: > As the implementer of an API, you must use one form or the other, or > hideously duplicate code.
That is philosophy. > It is TRIVIAL to convert from the > NUL-terminated form to the counted form, so that is what is usually > done. And is pretty much what SQLite does. I don't equate 'trivial' with 'hideously duplicate'. > (I will admit to being surprised that SQLite goes into two > levels of internal function calls before it converts, especially since > by that time it has put the text and text16 forms together.) It doesn't matter how levels it does internally. Internal functions tend to get inlined by the optimizer especially with the amalgamation. In any event the SQLite team will have done what is best in their opinions taking into account testability, maintenance, customer needs etc. They aren't idiots :-) > I went and looked for that performance optimization, and that > documentation. It applies only to sqlite3_prepare*(). Correct and what was discussed in this group. > The various > data methods do not have the same clause. And the data methods are > the only ones I would really expect NUL handling to be right. They are right - where exactly do you see a problem? > So is it in the bug system? I'm still very unclear what you think the actual bug is. > Using int instead of size_t A) unnaturally limits data length, > possibly to 64K SQLite doesn't work on 16 bit platforms so that is essentially unlikely. > The language needed size_t to provide a > type guaranteed to be sufficient to hold any sizeof() result, but no > API need use it. Most of the standard APIs like memcmp, strlen etc use size_t. When I looked at the various open source projects calling the data binding/return functions and passed in a size they would do so using APIs like the above that returned size_t. On 64 bit platforms it would then get truncated to fit 32 bit ints. > Right. The SQLite shell just assumes you are running in a uniform > character encoding environment (usually safe), and that it is UTF-8 > (safe for many users). Not even. It doesn't care if output is going to a file. You could quite happily put in garbage and get it back out. Regular C provides no i18n functionality anyway so there isn't much the code could do. It isn't SQLite style to use third party libraries. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6A1lIACgkQmOOfHg372QQYeACgqZkRZ8ivfJRAKey8/kOX0ZfI qIIAoKS+Ed+GwhYB67P2VCXiT21nLdBt =NTmo -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
