> 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.