Re: [AD] unicode proposal

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2009-01-23, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On 2009-01-22, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> > On Thu, 2009-01-22 at 17:34 +1100, Peter Wang wrote:
> > > 
> > > I basically agree with your function lists.
> > > 
> > 
> > I'll try to make a patch. Hard part will be changing all the code using
> > it.
> > 
> > > Later, I think I'd like to introduce explicit iterator types rather than
> > > bare pointers for ugetx (and give it a better name).  Also if sticking
> > > with UTF-8 (or even UTF-16) there's no reason not to introduce backwards
> > > traversal.
> > 
> > Iterator types?
> 
> Something like:
> 
>     struct ALLEGRO_STRING_POS {
> 	char *begin;
> 	char *pos;
> 	char *end;
>     };
> 
> so we can ensure begin <= pos <= end.

(Actually, this won't be needed.)

> > > The API is prone to buffer overflows and arbitrarily truncated strings
> > > due to the use of preallocated buffers.  Probably the solution is
> > > dynamic allocation.
> > 
> > Or do we go even further and use something akin to
> > http://bstring.sourceforge.net/ ?
> 
> Yeah, maybe.

I've played with it now, and it's nice.

I think we should finally introduce a new type for Unicode string
manipulation which performs dynamic memory allocation.  I've started on
one which uses bstring for its storage.  It's attached (work in
progress).

The idea is that you produce an ALLEGRO_USTR from a char* or afresh,
manipulate it, then get back a char* for printing out or whatever.
Outside of the string functions themselves, Allegro functions would
*not* take ALLEGRO_USTR arguments. Strings should still be char* so you
can give them C literals or use other another string APIs as you like.

Peter

Attachment: bstr_unicode.diff.gz
Description: application/gunzip