Re: [AD] utf16, file functions |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2009-03-18, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> I made a patch to add utf16 conversion as requested on the bug tracker.
> Is the API like you expected? Basically two functions:
>
> ALLEGRO_USTR *al_ustr_new_from_utf16(const char *s, size_t size)
>
> to go along with
>
> ALLEGRO_USTR *al_ustr_new_from_buffer(const char *s, size_t size)
That's fine.
>
> and
>
> char *al_utf16_dup(const ALLEGRO_USTR *us)
>
> to go along with
>
> char *al_cstr_dup(const ALLEGRO_USTR *us)
That should probably be uint16_t *al_utf16_dup(...);
Maybe it would be better to let the user allocate the memory, so you'd
have something like (made up just now):
size_t al_ustr_size_utf16(const ALLEGRO_USTR *us);
size_t al_ustr_encode_utf16(const ALLEGRO_USTR *us, int16_t *s, size_t n);
> There is no support for UTF-16BE and UTF-16LE. I assume filenames will
> always be returned in native order already - and it's probably the only
> use for those functions. Else it would be trivial to add 4 more
> functions with explicit endianness...
I also don't think it's necessary.
> I also wanted to replace the remaining uses of uconvert with this, but
> found that I'm confused about the state of our files API. Specifically:
>
> - What are src/win/wfile.c and src/unix/ufile.c? Are they superseded by
> src/fshook_stdio.c and can be removed?
>
> - What for is the addons/packfile directory? At first glance it looks
> like it was accidentally created during the fshook merge and has a copy
> of the old A4 API, so should it be removed?
...
> +/* Function: al_utf16_dup
> + */
> +char *al_utf16_dup(const ALLEGRO_USTR *us)
> +{
> + int pos = 0, sz;
> + char *ret;
> + ALLEGRO_USTR *utf16_char;
> + // TODO: Can ALLEGRO_USTR be used to hold UTF-16?
Yes.
Peter