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

[Omer Zak]

On Sun, 6 Jan 2002, Behdad Esfahbod wrote:

> 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 ;-).

I am glad that what I need for the EPOC 6 port will be useful also to
other people outside the circle of EPOC 6 users.

> > 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.

People may be using only a subset of header files.  So let's make the
bracketing fine-grained.

> 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*?

Okay, let's define the following structure:

struct FriBidiEnv {
  FriBidiList* iUsedListItems;  // Pointer to linked list of used list
                                // items.
  FriBidiList* iFreeListItems;  // Pointer to linked list of free list
                                // items.  Allocation requests are
                                // satisfied first from this list, then
                                // from regular malloc().
  // The FriBidiList structure will either have an extra pointer for
  // memory management support, or else we'll use existing pointers
  // for this purpose.
  // TO BE CHECKED:  if we allocate and free only one data structure
  //                 or more than one different data structures.
  //                 This affects handling the above lists.
  FriBidiFlags iFlags;
  // The flags will define:
  // - Debug mode
  // - Mirroring
  // - L3 rule on/off
  // - remove BiDi marks on/off
  // - Arabic joining on/off
  // - Ligaturing on/off
  // They will be set and cleared by inlined access procedures.
};

In addition, let's replace all malloc() and free() calls by
fribidi_malloc() and fribidi_free() calls.  For now, they'll be #define'd
to be the same as malloc() and free().  But next version we'll add the
environment parameter.
                                             --- Omer
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html