Here is a fixed version of the patch. On Thu, Jan 29, 2015 at 10:29 AM, Timur Kristóf <timur.kristof(a)gmail.com&gt; wrote:

Timur Kristóf wrote: It looks OK to me. No one raises any concerns I'll commit it in a few hours. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

On 02/02/15 02:00, Hallvard Breien Furuseth wrote: ...and there will now be database names which cannot be spelled on the command line, like for <mdb_stat/mdb_dump -s subdb>. I don't think that was quite the point.

My take: On 27. jan. 2015 22:39, Timur Kristóf wrote: MDB_val here sounds nice... My initial reaction is that an API with different prototypes for Windows and Unix sounds bad. Unix must have char* since it does not even support wchar_t* filenames, and it should be simple to write a portable OS-unaware LDMB program. Though I notice Windows #defines CreateFile() & co as CreateFileA or CreateFileW depending on whether or not UNICODE is #defined (and some other macros), without even mentioning this in the CreateFile() doc. I suppose ldmb.h could do something similar - but with doc:-) What's the norm for Windows libraries? Google found TCHAR stuff which becomes WCHAR or char depending on defined(UNICODE), and apparently strong religions about whether if it's a good or bad idea for portable libraries to do the same. #define MDB_TEXT(str) as str or L##str depending on UNICODE, etc. -- Hallvard

I've had a brief chat with Hallvard on IRC. We came up with several possible solutions, although each of them has its drawbacks. Writing cross-platform code that supports unicode is always a messy business. I vote for option 4, but would like to hear everyone's opinions before starting to work on any of them. 1) Separate widechar functions Make functions such as mdb_env_open_w that would call the widechar APIs. The drawback of this approach is that it would require a lot of duplicate code, which is hard to maintain. It would also pollute the lmdb header file. 2) New flag Introduce a new flag (such as MDB_USE_WCHAR) that would tell mdb_dbi_open to cast the path parameter to wchar_t* under the hood and call the widechar variant of the windows api. Advantage: only the string concatenation code would need to be duplicated Drawback: it is really-really ugly 3) Require UTF-16 on Windows Since Microsoft discourages the use of their ANSI apis, we could say that we require UTF-16 on windows. We can make a type such as mdb_uchar_t that we would typedef to char on unix and wchar_t on windows and then we could change the function signatures to use this type. Drawback: users that want to write cross-platform code would need to ifdef their calls to mdb_env_open 4) Require UTF-8 on Windows Let's say we require the path parameter to be encoded in UTF-8, even on windows. Then under the hood we can convert it to UTF-16 and call the widechar APIs. This doesn't lead to loss of performance because windows itself converts to UTF-16 anyway if you use their ANSI functions. This is the least ugly and perhaps the easiest-to-implement solution we found. It is easy to make UTF-8 (most libraries can produce it, or the user could use u8"..." from C++11, etc.) Advantage: this is the easiest to implement; code that worked before (with ASCII paths) will work without modification, and we don't need to duplicate any code.