Tim, I'm not sure of what all SQLITE_UTF8 affects; however, I can clarify that my proposal doesn't require that SQLITE_UTF8 be used. My only point was that the sqlite functions require 'narrow' chars (UTF-8 or not), so why not always call the narrow 'A' versions of Windows functions? Chris gave me the answer: because WinCE, for example, doesn't support the narrow versions.
-----Original Message----- From: Tim McDaniel [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 3:39 PM To: [EMAIL PROTECTED] Subject: RE: [sqlite] Win32 coders: change os.c? Importance: Low Maybe there needs to be some clarification here. All the sqlite functions take const char* for string parameters. What I'm not clear on is the intended effect of the SQLITE_UTF8 macro. Which string parameters of which functions are intended to be UTF-8 encoded if the SQLITE_UTF8 macro is defined? I have assumed that it is only those string parameters which are SQL statements. Tim > -----Original Message----- > From: Rob Fowler [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 3:14 PM > To: [EMAIL PROTECTED] > Subject: RE: [sqlite] Win32 coders: change os.c? > > > Thanks for your thoughts. Your first proposal (as I > understand it) creates unnecessary steps to end up with data > that Sqlite can use. Here's an example of the round trip > flow of data in your proposal: > > User input (UTF-16) > -> UTF16_To_UTF8() > -> sqlite_function() > -> MultiByteToWideChar() > -> Win32FunctionW() > -> WideCharToMultiByte() > -> Data Sqlite can use > > Why the conversion back to wide characters within SQLite? In > my proposal, the flow is as follows: > > User input (UTF-16) > -> UTF16_To_UTF8() > -> sqlite_function() > -> Win32FunctionA() > -> Data Sqlite can use > > Your second proposal is to prevent me from using UNICODE > within my parent application? Can't do that. Na�ve > programmers will already know something needs to be done > (convert UTF-16 to UTF-8) in order to use the sqlite > functions in the first place. Their app won't compile if > they try to feed in wide strings. > > Any follow-up thoughts? > > Rob > > -----Original Message----- > From: Arthur Hsu [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 2:24 PM > To: [EMAIL PROTECTED] > Subject: Re: [sqlite] Win32 coders: change os.c? > Importance: Low > > > Not quite. IMHO, it's better that os.c catches this UNICODE > macro, and then > > uses MultiByteToWideChar and WideCharToMultiByte inside. The > other way is > > to use an assert(FALSE) to prevent compilation using UNICODE, > then the naive > > programmers like me will know something needs to be taken care of. > > > > -Arthur > > > > ----- Original Message ----- > > I think you can see where I'm going with this. To fix the problem, I > > propose that for the functions listed above, os.c should > always call the > > 'real' function name, and it should be the one ending with an > 'A'. As it > > stands, the os.c has no ability to deal with wide characters, > so there is no > > reason it should ever call the wide version of these Win32 functions. > > > > Thoughts? > > > > Regards, > > Rob Fowler > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
