Re: Uninitalized Face data

[Arnar Mar Hrafnkelsson]

I actually did read that part of apiref.txt.  The reason for
going to the headers is that I was looking for something that might
be ommited from the documentation (The documentation is excellent btw).

While waiting for the reply - I used something like:

#define USTRCT(x) (x.z)

...

if (USTRCT(glyph[i]) == NULL) { get glyph in place }


The common theme seems to be that this is always hierarchical 
structure to the deallocation of structures.


If an Face is removed an instance is removed
if an instance is removed all of its glyphs and
Charmaps are removed ( not sure about this part btw ).

I have a structure that holds the face and some external
information to that.  One of the members is an array of 
structures where an instance is one of the members.

Each such structure holds an array of glyphs as well.

Deallocation is always safe from above it seems - If a 
higher level structure is removed you do not have to remove the lower
level ones.

The data seemed to be always represented by a pointer - and checking
against NULL seems logical since many operating systems SEGFAULT on all
dereferences close to zero.

I hope I'm not making (m)any wrong assumptions.

As a user of the library, I'm all in favor of some simple method to 
check the validity of data in the general pointer convention.

I'm not running this in a multithreaded configuration - I don't know how
freetype behaves in such a scenario but I could imagine that my suggestion
would be much more dangerous in that case ( well maybe if it were
atomically possible to dealloc and assign NULL to the data ).

        Arnar.


On Thu, 24 Feb 2000, Antoine Leca wrote:

> Arnar Mar Hrafnkelsson wrote:
> > 
> > If I have an array of instance handles say:
> > 
> > int i;
> > TT_instance instance[10];
> > 
> > for(i=0;i<10;i++) {
> >   instance[i]=NULL;  /* this is the part that
> >                         it doesn't like */
> > }
> 
> Neither do I ;-)
> 
> You are suposed to create the instances with something like:
> 
>   for(i=0;i<10;i++) {
>     TT_New_Instance(some_face, instance[i]);
>   }
> 
>  
> > The reason is that freetype arranges TT_instance like:
> > 
> > struct TT_Instance_ { void*  z; };
> > typedef struct TT_Instance_  TT_Instance;
> 
> Well, you did cheat by looking at the sources without:
>  - reading the doc (and in particular docs/apiref.txt)
>  - reading the comments that are just above the part you copied.
>   Here is a more larger extract:
> ]   /* Here are the definitions of the handle types used for FreeType's */
> ]   /* most common objects accessed by the client application.  We use  */
> ]   /* a simple trick:                                                  */
> ]   /*                                                                  */
> ]   /*   Each handle type is a structure that only contains one         */
> ]   /*   pointer.  The advantage of structures is that they are         */
> ]   /*   mutually exclusive types.  We could have defined the           */
> ]   /*   following types:                                               */
> ]   /*                                                                  */
> ]   /*     typedef void*  TT_Stream;                                    */
> ]   /*     typedef void*  TT_Face;                                      */
> ]   /*     typedef void*  TT_Instance;                                  */
> ]   /*     typedef void*  TT_Glyph;                                     */
> ]   /*     typedef void*  TT_CharMap;                                   */
> ]   /*                                                                  */
> ]   /*   but these would have allowed lines like:                       */
> ]   /*                                                                  */
> ]   /*      stream = instance;                                          */
> ]   /*                                                                  */
> ]   /*   in the client code this would be a severe bug, unnoticed       */
> ]   /*   by the compiler!                                               */
> ]   /*                                                                  */
> ]   /*   Thus, we enforce type checking with a simple language          */
> ]  /*   trick...                                                       */
> ]  /*                                                                  */
> ]  /*   NOTE:  Some macros are defined in tttypes.h to perform         */
> ]  /*          automatic type conversions for library hackers...       */
> 
>  
> > It seems that I have two choices -
> > 
> > 1) Check the internal z pointer
> >   - which would seem like doing something I shouldn't be doing.
> 
> If you do that, you qualify yourself as:
> - a library hacker, since you access datas that are supposed to
> be hidden, as explained above
> - ... which does reinvent the wheel, because the usage of the z
> pointer is exactly what the macros (cited above) do.
> 
>  
> > 2) Create an array of pointers to TT_instance and dereference all the
> > time.
> 
> I see another solution: instead of using an array of TT_instance,
> you create an array of structures, which structures contains:
>  - a TT_Instance object (which is a handle);
>  - everything your application might also need (in your case,
>   I believe a flag to signal if the instance is initialised or
>   not is what you are presently asking for).
> 
> >   - This is a tad annoying since this seems to be a pointer anyway.
> > 
> > It would be nice to have some macros like: Not_Null( instance );
> > but from what I gathered in the documentation they were mostly for
> > internals programming.
> 
> To know if a handle to an instance still is valid is not a straight-
> forward task, indeed (need to check on deallocation of the instance
> via TT_Done_Instance, as well as `indirect' ways like de-allocating
> the face). This is even worse for TT_Glyph I believe.
> 
> David, is it an idea for new API?
> 
> 
> Antoine
>