Dear,
(1)
It looks like the appropriate character set mapping behavior on Windows is
still not quite right in the command line utility. I'm currently reviewing the
code and it looks like it revolves around the sqlite3_win32_mbcs_to_utf8() API
(and reciprocal) which in turns calls winMbcsToUnicode() and reciprocal. Those
do this:
int codepage = osAreFileApisANSI() ? CP_ACP : CP_OEMCP;
and if this is quite right for a filename, it is not for the content read-in or
written-out from/to the console, which should use CP_OEMCP.
By default on Windows the ...A version of file APIs are using 'ANSI' (for the
encoding of the filenames they expect or return - nothing to with the encoding
of whatever is read or written). They can be changed to using 'OEM' encoding,
which might be simpler for some console programming but is generally not the
thing to do. The console I/O itself always requires by default CP_OEMCP which
maps to whatever specific 'code page' the console is actually using.
In other words, all things default, a filename passed to CreateFileA should be
ANSI (unless osAreFileApisANSI() says the no), but the data read or written
from stdin/stdout/stderr when interactive should use CP_OEMCP.
I'll try to patch a proper solution over these next days as time permit and I
will propose it. It might find its way in some next 3.11.x release. I need to
get more acquainted with the existing code and its intent, first.
I think the shell.c program might have its own oem_to_utf8() and utf8_to_oem(),
which are not needed in the engine sqlite3.c, for translating interactive
console I/O, and leave sqlite32_win32_mbcs_to_utf8() as is in the engine, for
whatever it is currently used for (if at all).
(2)
This will trigger a warning on 64 bits compile (at least on C++ MSVC compiler):
static int fts5ConfigSetEnum(
const Fts5Enum *aEnum,
const char *zEnum,
int *peVal
){
int nEnum = strlen(zEnum); <<-- strlen returns size_t (64 bits)
Same thing in:
static int fts5ExprPopulatePoslistsCb(
void *pCtx, /* Copy of 2nd argument to xTokenize() */
int tflags, /* Mask of FTS5_TOKEN_* flags */
const char *pToken, /* Pointer to buffer containing token */
int nToken, /* Size of token in bytes */
int iStart, /* Byte offset of token within input text */
int iEnd /* Byte offset of end of token within input text */
){
Fts5ExprCtx *p = (Fts5ExprCtx*)pCtx;
Fts5Expr *pExpr = p->pExpr;
int i;
if( (tflags & FTS5_TOKEN_COLOCATED)==0 ) p->iOff++;
for(i=0; i<pExpr->nPhrase; i++){
Fts5ExprTerm *pTerm;
if( p->aPopulator[i].bOk==0 ) continue;
for(pTerm=&pExpr->apExprPhrase[i]->aTerm[0]; pTerm; pTerm=pTerm->pSynonym){
int nTerm = strlen(pTerm->zTerm); <<<--- strlen returns size_t (64 bits)
--
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om
> Le 10 f?vr. 2016 ? 15:02, Richard Hipp <drh at sqlite.org> a ?crit :
>
> The "Pre-release Snapshot" on the download page
> (https://www.sqlite.org/download.html) is very close to what will
> ultimately be released as SQLite version 3.11.0. A summary of changes
> can be seen at (https://www.sqlite.org/draft/releaselog/3_11_0.html).
>
> If you are able, please give the 3.11.0 beta a try and let us know if
> you encounter any issues. You can reply to this mailing list, or
> directly to me.
>
> A release check-list for version 3.11.0
> (https://www.sqlite.org/checklists/3110000/index) is now on-line. At
> some point (not today, but probably soon) we will start marking off
> items from this check-list. Once all the items have been marked as
> "pass" (and turn green) we will cut the release.
> --
> D. Richard Hipp
> drh at sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/attachments/20160211/248c8cb9/attachment.pgp>
