Re: [AD] Allegro unable to deal with non ascii filenames

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2006-05-30 at 14:42 +0200, Hein Zelle wrote:
> Chris wrote:
> 
> > Whatever you write, you'll get back. If I create a filename with the
> > bytes 0xC0 0x86, then use readdir and get that file, I'll see those
> > two bytes, always. You'll not be any wiser. You'll have to know what
> > those bytes mean to get any real information. The issue is Allegro
> > is assuming UTF-8 in ufile.c and the ASCII default with unlink/open
> > (and when it converts to/from an improper ASCII codepage from UTF-8,
> > you'll mix up/lose the extended characters).
> 
> Just out of interest, why is it necessary to do any file name
> conversion at all?  I don't understand why a conversion is being done
> on the filenames coming out of readdir (or findfirst) in the first
> place.  Assuming that there are libc functions like fopen that know
> how to deal with unicode strings, can't we just keep filenames as an
> arbitrary string of bytes and pass those along to the relevant libc
> file functions?

That's what seems to be the libc suggestion, yes. And I'm thinking if we
maybe can do this for 4.3.

> I've not done anything with unicode strings myself sofar, so this is
> probably something very basic.  I could understand problems arising if
> allegro was manipulating filenames somehow (copying, allocating
> buffers for the strings) without knowing the encoding, but I am not
> sure why it would manipulate the filenames in the first place?
> 

Currently, Allegro uses its own string functions (e.g. when you call
textprintf_ex) - so all strings must be in Allegro's encoding. Changing
this is not a completely trivial task. E.g. the text output must use
only libc functions to extract the single unicode glyph numbers.. I'm
not even sure it is possible yet.

-- 
Elias Pschernig