> Another note regarding the fsys module API. Currently this API uses > pdf_text_t objects as input path arguments. This ends up being far from > optimal. Also, pdf_text_t to host encoding conversion doesn't include > trailing NUL bytes by default, which ends up requiring an additional > realloc() after the conversion to add these end-of-string NUL bytes. I > think its reasonable to change the API so that the fsys API gets as > input always host-encoded strings represented by NUL-terminated > (pdf_char_t *) instead of (pdf_text_t *) (or 2-NUL terminated wide char > strings in windows). > > 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? -- Aleksander
