[Fribidi-discuss] Starting to work on EPOC 6 port of FriBidi

[Behdad Esfahbod]

On Sun, 6 Jan 2002, Omer Zak wrote:
> I started to work on the Symbian EPOC 6 port of FriBidi.
> The following issues were encountered:

Good, I'm thinking of porting it go PalmOS 4.0 too, but I'm quite busy 
now, just mentioned to let you know that I'm interested in helping you 
in your port ;-).

> 1. EPOC 6 uses C++.  It would be nicer if the header files bracket
>    their stuff with:
> 
>         #ifdef __cplusplus
>         extern "C" {
>         #endif
>           .
>           .
>           .
>         #ifdef __cplusplus
>         }
>         #endif

Yes, I thought that it's enough to add this in fribidi.h, and did it, 
I will add it in other headers too.

> 2. There are problems in using static variables in EPOC 6.
>    It would be easier if all top-level constants (tables, FriBidi help
>    string, etc.) have 'const' in their declarations.

I know this one too, in my near fribidi todo list is to add lots of 
const keywords here and there (in prototypes, declarations, ...).

> 3. The static boolean mirroring = TRUE; is a NO-NO in EPOC 6, and would
>    also prevent the FriBidi library from being reentrant (important in
>    multi-tasking and multi-threading environments - if not in Unix based
>    operating systems, at least in other operating systems).

And, surprisingly, I know this one too :-), as in PalmOS the libraries 
cannot have any global variables too.

> 4. While I didn't look closely into malloc/free calls, it would be nice
>    to have a mechanism for handling memory allocation failure and
>    guaranteeing cleanup in case of any interruption of execution of the
>    FriBidi code.

I didn't try to do anything in this way because of other more 
important issues, next step I will define some functions in 
fribidi_mem.[ch], and push other fribidi source files to allocate and 
free just through this functions, to have full control on the memory 
related things, then we can add some configure options to check the 
result from malloc, ...

> Problems (3),(4) can be solved if the relevant functions receive another
> parameter (yes, version 3 of the interface and another macro definition
> for Nadav et. al.).  The parameter (inspired by the idea of the
> implicit 'this' argument in C++ class methods) will be a void* pointer
> (typedef'ed into FriBidiEnvironment).  It will point at an
> implementation-defined data structure, which will hold the right value for
> boolean mirroring (and other static variables, if any), and also pointers
> for managing the dynamically allocated data structures.

Why void*? why not FriBidiEnv*?

Don't worry about interface 3, I'm adding lots of new api, that makes 
life really easy, everyone then will migrate to the new one ;-).

> The caller of fribidi procedures is responsible for allocating,
> initializing and destroying (it must explicitly destroy, because this is
> how memory gets freed) the FriBidiEnvironment data structure (by means of
> functions provided by FriBidi).

When I was first adding the definitions of mirroring, debug, ... I 
wondered if I should do this or not, I did it this way because it was 
just one or two that time, but it will be growing with time, next 
verison may have some other options like ones to turn rule L3 on or 
off, removing bidi marks on or off, arabic joining on or off, and far 
later, ligaturing on or off... (just dreaming), then we really need 
the environment, I will work on this.

> I am willing to carry out the actual modifications, but I'd like first to
> see if there are any objections to the above suggestions and to their
> incorporation into plain vanilla FriBidi (rather than as a forked
> version).

No objection at all, but make it an interactive discussion on list, 
I'm a little busy (with exams) to do it myself.

>                                              --- Omer
> WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html

-- 
Behdad
16 Dey 1380, 2002 Jan 6

[Finger for Geek Code]