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





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/