Re: [pdf-devel] Help needed for FS#39

[Aleksander Morgado]

> 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