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

[Hein Zelle <hein@xxxxxxxxxx>]

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?

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?

Hein Zelle

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-< 
 Unix is user friendly. It's just very particular about who 
 it's friends are.

 Hein Zelle                     hein@xxxxxxxxxx
	                        http://www.icce.rug.nl/~hein
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<