Re: GLib Patch

[Owen Taylor <otaylor redhat com>]

Andrew Taylor <andrew taylor montage ca> writes:

> Hi all.
> 
> I have made a patch for glib available here:
> http://bugzilla.gnome.org/show_bug.cgi?id=64433.  This patches
> gen-unicode-tables.pl to make the tables more shared library
> friendly. In particular, it implements the suggestions from this
> discussion:
> http://mail.gnome.org/archives/gtk-devel-list/2001-September/msg00601.html.

I've applied the patch, thanks!

If you are into this type of project, there are two more you
could tackle:

 A) gunidecomp.h is a far worse offender for relocations than
    the stuff you fixed ... it has about 3500 relocations!

    The records here are in the form:

   typedef struct
   {
     unsigned short ch;
     unsigned char canon_offset;
     unsigned char compat_offset;
     unsigned char *expansion;
   } decomposition;

   static const decomposition decomp_table[] =
      { 0x00a0, 255, 0, "\x00\x20\0" },

   So there is a relocation per record. One obvious approach to
   removing relocations would be to have:

   typedef struct
   {
     unsigned short ch;
     unsigned char canon_offset;
     unsigned char compat_offset;
     unsigned char expansion[MAXLEN];
   } decomposition;

   With the extra space taken for an expansion of LEN bytes
   being.

    MAXLEN - LEN - 4 

   bytes. Unfortunately, the expansions vary quite a bit
   in size, with some being very long. One approach to
   dealing with this would be to "special case" the long
   expansions and have the expansion[] field encode a
   pointer into an exception table.

   A simpler approach would be simply have indirection
   with:

     unsigned gushort expansion_index;

   Being an offset into a simple char * holding all the 
   expansions concatenated together; I think this is
   probably the right approach.

 B) Handle the allocations outside of the BMP in
    Unicode-3.1. (http://www.unicode.org/reports/tr27)

    This probably will require some reworking of table
    formats to do this without expanding table sizes
    too much. Also, some special casing may be necessary -
    e.g. the plane 15 tag characters might need to
    certainly be handled as exceptions rather than in
    tables since they are very far from the other allocations.

Regards,
                                        Owen