[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Help needed for FS#39
From: |
Aleksander Morgado |
Subject: |
Re: [pdf-devel] Help needed for FS#39 |
Date: |
Sun, 27 Mar 2011 19:55:01 +0200 |
> 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