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

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2007-02-07, Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx> wrote:
> On 2006-12-27, Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx> wrote:
> > [...] Rather than start commiting changes like crazy we need to
> > think of the correct solution before acting.  [..]
> 
> I guess I can start hacking on this soon opening a branch in svn, and
> leave decisions/testing for later.

I read your (long) message but forgot to reply to this back then.
Basically I agree with your proposal.

>  1. Find out how filesystem encoding is dealt on each platform.

Fine.

>  2. Build a list of filesystem conversion tables for systems where
>  glibc/iconv is not available (only DOS?).

Practically speaking, I don't think anyone will expend the energy to
fixing this issue on DOS, even if it were technically possible.
Forget it.

>  3. Decide on an abstraction layer which would allow Allegro code to
>  wrap all filenames in calls to conversion functions.

I had an idea of how to enforce this, and ensure conversions exactly
once only.  We can introduce a type which is different from char* so
that the compiler can type check where we have missed a conversion or
not, e.g.

    typedef struct {
	...
    } al_fs_string_t;

That is, the user deals in char* strings but internally we convert and
pass around al_fs_string_t* objects.

I'd also look again at Annie & Vincent's UBUFFER patch.  We should have
looked at that again for 4.2.0.

>  4. Make the abstraction layer public, because end programmers are going
>  to need it too for their own al_findfirst() tinkering.
>  5. Implement it for 4.2 branch.

Peter