FriBidiEnv (was: Re: [Fribidi-discuss] Starting to work on EPOC 6 port of FriBidi)

[Omer Zak]

On Tue, 22 Jan 2002, Behdad Esfahbod wrote:

> On Sat, 19 Jan 2002, Omer Zak wrote:
> > Hello Behdad,
> > Okay.
> >
> > 1. I suggest that any function, which needs the FriBidiEnv, first validate
> >  it by a macro call:
> >
> >  FriBidiResult fribidi_do_something(FriBidiEnv *env, s, s_len,...)
> >  {
> >    VALIDATE_FRIBIDIENV(env);
> >    do_other_stuff("TM");
> >    return((FriBidiResult) "Great FriBidiResult (TM)");
> >  }
>
> And what FriBidiResult is going to be? currently most of them return
> booleans, also we can have a status flag and error message in
> FriBidiEnv type...

Ignore it, it was just a random string created for the example (like the
nonexistent function do_other_stuff()).

By the way, the "validation rule", which emerges from the code, is that
only functions, which need to access FriBidiEnv fields - need to validate
it.  Functions, which just pass its pointer to other functiosn - don't
need to validate it themselves.

> > 2. About API names - for now, I assume that not too many projects are
> >  bound to the interface used by version 0.10.0, so let's use the same
> >  flag for the interface with implicit strlen()'s and for NULL
> >  FriBidiEnvs.
>
> But I like explicit strlens more ;).I should think more about the
> charset converters...

I am afraid I did not clarify myself.

Now we have three possible interfaces:
1. Old FriBidi (implicit strlen(), no FriBidiEnv).
2. Current FriBidi (explicit strlen(), no FriBidiEnv).
3. New FriBidi (explicit strlen(), with FriBidiEnv).

The question is whether we need to support people who work with interface
(2), or can we tell them that we don't want to bother with supporting
interface (2).  My position - interface (2) has existed for such short
time (few weeks) that we can afford not to support it in the future.

> > 3. From what I saw in FriBidi code, it needs to malloc and free memory
> >  chunks of various sizes.  How can this be managed?
>
> Would you please explain more.

If the memory chunks were all of the same size, it would have been
possible to allocate/free them using a linked list based memory pool.
However, this is not relevant now, after I implemented in FriBidiEnv a
double-linked list based scheme for allocating, freeing and cleaning up
allocated memory in case of exceptions.  This code has been E-mailed to
the mailing list.
                                             --- Omer
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html