Re: [sqlite] Checking for errors in sqlite3_column_*
Hello! I noticed that there was some discussion about mailing list messages getting sent to spam boxes. So, not that I expect an immediate answer, but just in case people didn’t see this message for that reason, here it is again. It seemed potentially odd that many other threads got replies but this didn’t. On Thu, 7 Jun 2018 20:14:35 -0700 Christopher Head wrote: > Hello, > I have a question regarding checking for errors that occur when > calling sqlite3_column_*. > > From this manual page: > > https://sqlite.org/c3ref/column_blob.html > > it seems that the only error that could occur (other than programmer > error, like out-of-bounds column index or calling it after something > other than SQLITE_ROW) is memory allocation error. That page says > that, in the event of memory allocation error, an appropriate default > value is returned and then sqlite3_errcode will return SQLITE_NOMEM. > > From this manual page: > > https://sqlite.org/c3ref/errcode.html > > it states explicitly that, if the most recent call failed, then > sqlite3_errcode returns the error code, but if the most recent call > succeeded, then the return value is undefined. > > So how do I check if sqlite3_column_int failed due to memory > allocation error? If sqlite3_column_int returns zero, I don’t know > whether it succeeded or failed. In the event that it succeeded, then > the return value from sqlite3_errcode is undefined. So even if > sqlite3_column_int returns zero and sqlite3_errcode returns > SQLITE_NOMEM, it could be that an allocation failed, but it could > just as well be that the actual column value was zero and > sqlite3_errcode randomly decided to return SQLITE_NOMEM because the > return value is undefined because sqlite3_column_int succeeded. > > I discovered from inspecting the source code (and then confirmed by > testing) that if an sqlite3_column_* function fails, then the next > sqlite3_step call will *also* fail with SQLITE_NOMEM (and that’s > detectable because sqlite3_step returns a result code as its return > value), but that doesn’t seem to be documented anywhere in the manual > at all. > > So what’s the proper way to check for errors in these functions? > > Thanks! -- Christopher Head pgpC81VZwXE36.pgp Description: OpenPGP digital signature ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Checking for errors in sqlite3_column_*
Hello, I have a question regarding checking for errors that occur when calling sqlite3_column_*. From this manual page: https://sqlite.org/c3ref/column_blob.html it seems that the only error that could occur (other than programmer error, like out-of-bounds column index or calling it after something other than SQLITE_ROW) is memory allocation error. That page says that, in the event of memory allocation error, an appropriate default value is returned and then sqlite3_errcode will return SQLITE_NOMEM. From this manual page: https://sqlite.org/c3ref/errcode.html it states explicitly that, if the most recent call failed, then sqlite3_errcode returns the error code, but if the most recent call succeeded, then the return value is undefined. So how do I check if sqlite3_column_int failed due to memory allocation error? If sqlite3_column_int returns zero, I don’t know whether it succeeded or failed. In the event that it succeeded, then the return value from sqlite3_errcode is undefined. So even if sqlite3_column_int returns zero and sqlite3_errcode returns SQLITE_NOMEM, it could be that an allocation failed, but it could just as well be that the actual column value was zero and sqlite3_errcode randomly decided to return SQLITE_NOMEM because the return value is undefined because sqlite3_column_int succeeded. I discovered from inspecting the source code (and then confirmed by testing) that if an sqlite3_column_* function fails, then the next sqlite3_step call will *also* fail with SQLITE_NOMEM (and that’s detectable because sqlite3_step returns a result code as its return value), but that doesn’t seem to be documented anywhere in the manual at all. So what’s the proper way to check for errors in these functions? Thanks! -- Christopher Head pgpTnVwWkaqQ0.pgp Description: OpenPGP digital signature ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Filename encoding on Unix platforms
Thanks to all who replied. Richard, you specifically said that “on posix, filenames are expected to be UTF8”; sorry, I’m not very familiar with the POSIX standard, but I wasn’t aware that was the case? This page: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271 seems to suggest that a pathname may not be in any specific character encoding, and, in fact, may not even be a “character string” (i.e. text). It doesn’t mention UTF-8. Anyway, now that I know the plan is not to change SQLite’s behaviour, I’ll treat it accordingly. -- Christopher Head pgpX7at_u_3HN.pgp Description: OpenPGP digital signature ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Filename encoding on Unix platforms
Hello, I have a question regarding text encoding of filenames on Unix platforms. I’ve read the two related mailing list threads I could find in the archive, <https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg35875.html> and <https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg94184.html>. Both of those explain that, on Unix platforms, the filename string is passed unmodified by SQLite directly to the open() syscall. From what I understand from reading a lot of information on the Internet, this may or may not be correct, and nobody can agree. It seems that, taking a survey of other software, GLib expects filenames to always be UTF-8 but allows that to be changed via environment variable, Qt expects filenames to always be in the locale encoding, and Coreutils (“ls”) also expects filenames to be in the locale encoding (at least, it sometimes decides to show filenames in '$'\XYZ escaped form, and it decides whether or not to do that based on your $LANG and co. variables, in a way which is consistent with it considering filename to be locale encoded). It seems, though I could be wrong, that more people fall on the “locale encoded” side than on the “always UTF-8” side (though thank goodness it’s becoming less and less relevant as more and more systems are running with UTF-8 locales anyway). My question is this: In those two mailing list posts, it was explained that SQLite’s current behaviour is to pass the string unmodified to the open() syscall. Is this just an explanation of current behaviour, or is it an official policy? That is to say, which of the following statements is correct? (1) SQLite developers believe that Unix filenames should be UTF-8 at the syscall layer regardless of your locale, and therefore if your particular box has a non-UTF-8 file on its disk, you shouldn’t be able to access it. (2) SQLite developers believe that Unix filenames should be locale-encoded at the syscall layer, and therefore the missing transcode is a bug. (3) SQLite developers refuse to get into this argument and think it’s up to the developer of the client application, who should pass a string of whatever encoding they think right into sqlite_open() which in turn passes it on to open(). I can’t really tell which of these is the official policy. If it’s #1, the documentation and code are both fine, though it makes some files inaccessible for some users. If it’s #2, the documentation and the code are both wrong. If it’s #3, I think it would make sense if the documentation were updated to explain this. The reason I ask is because, in addition to the current behaviour (easy to find out just by testing or reading the source code), I want some idea of whether this might change in future. That is, if I just write “known bug” and insert a workaround in my client code to pass a locale string to sqlite_open() instead of a UTF-8 string, is that workaround going to break sometime in future when the bug (if you consider it a bug) gets fixed? Thanks for the clarification, and please note that I am not subscribed to this list so I would appreciate being included explicitly in replies. -- Christopher Head pgpGC4T9j_U9d.pgp Description: OpenPGP digital signature ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
