On Mon, 28 Mar 2011, Jose E. Marchesi wrote:
> So the module would be offering two different APIs, depending on which > kind of system it is running on? Considering that the fsys module > allows many different backend implementations, would be a pdf_char_t* > based API flexible enough? Well, in all systems the APIs would offer as input an array of NUL-terminated characters. In GNU systems, that's a standard single-NUL-terminated string; in Windows, it would be a 2-NUL-terminated string (a NUL wide char). If this is confusing, we can leave the pdf_text_t as input path object; but that would usually imply from/to conversions to host encoding... maybe not a big deal? Well, the fact windows wide chars are using the double NUL termination shall be pretty transparent for the programmer, right? It is the need of changing the interface of the fsys module, depending on the running system, what worries me.
it's wide chars only if the macro UNICODE is defined, which is not always the case. By default, mingw does not define it, while Visual Studio does.
Vincent Torri
