Re: [AD] al_font_textprintf() and uvszprintf()

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Wed, 2008-10-29 at 16:58 +0100, Evert Glebbeek wrote:
> Currently, al_font_textprintf() allocates a static buffer of size 512  
> characters. While I'm sure that's plenty for any line of text anyone  
> is likely to want to display on a monitor in ASCII on a current  
> monitor, it's an arbitrary limit and it's probably not particularly  
> safe when having unicode output. Should this be increased? Or better  
> yet, a way found to increase the size of the buffer dynamically as  
> needed?

Yes, we should not hardcode sizes if there is a chance they are too
small. Before the A5 release we probably should reserve a day or so
where we check all code for hardcoded limits used in that way. (Another
one I remember is the config system, it sets a limit on the size of
entry names/values right now.)

> 
> Secondly, it uses uvszprintf(), which is fine in principle, but  
> uvszprintf() is an Allegro function that is missing the al_ prefix.  
> Should it acquire one? I can think of reasons why maybe it shouldn't,  
> but it does seem to violate A5's intention of not polluting the  
> global namespace.
> 

We never came to a final conclusion yet what to do about unicode I
think. Prefixing the A4 API with al_ seems to be a good start to me -
however there's some unsolved problems with it (e.g. a proper
implementation of ustricmp needs to do more than the A4 one).

Also, do we want to keep support for codepages? Support for UTF16? Or is
just UTF8 (with 7-bit ASCII included as a subset) enough?

-- 
Elias Pschernig <elias@xxxxxxxxxx>