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

[Jose E. Marchesi]

    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?

-- 
Jose E. Marchesi    address@hidden
GNU Project         http://www.gnu.org