Re: [Emacs-diffs] trunk r117464: Shrink Lisp_Sub_Char_Table by preferring C integers to Lisp_Objects.

[Stefan Monnier]

> @@ -1465,10 +1466,10 @@
>         contains 32 elements, and each element covers 128 characters.  A
>         sub char-table of depth 3 contains 128 elements, and each element
>         is for one character.  */
> -    Lisp_Object depth;
> +    int depth;
 
>      /* Minimum character covered by the sub char-table.  */
> -    Lisp_Object min_char;
> +    int min_char;
 
>      /* Use set_sub_char_table_contents to set this.  */
>      Lisp_Object contents[FLEXIBLE_ARRAY_MEMBER];
> @@ -1539,12 +1540,16 @@
>      const char *doc;
>    };
 
> -/* This is the number of slots that every char table must have.  This
> -   counts the ordinary slots and the top, defalt, parent, and purpose
> -   slots.  */
> -enum CHAR_TABLE_STANDARD_SLOTS
> +enum char_table_specials
>    {
> -    CHAR_TABLE_STANDARD_SLOTS = PSEUDOVECSIZE (struct Lisp_Char_Table, 
> extras)
> +    /* This is the number of slots that every char table must have.  This
> +       counts the ordinary slots and the top, defalt, parent, and purpose
> +       slots.  */
> +    CHAR_TABLE_STANDARD_SLOTS = PSEUDOVECSIZE (struct Lisp_Char_Table, 
> extras),
> +
> +    /* This is an index of first Lisp_Object field in Lisp_Sub_Char_Table
> +       when the latter is treated as an ordinary Lisp_Vector.  */
> +    SUB_CHAR_TABLE_OFFSET = PSEUDOVECSIZE (struct Lisp_Sub_Char_Table, 
> contents)
>    };
 
Are we sure this SUB_CHAR_TABLE_OFFSET exists?  I don't see any reason
why `contents' should necessarily be aligned on a multiple of Lisp_Objects.
So, I think it's unsafe to cast your new "struct Lisp_Sub_Char_Table"
to a "struct Lisp_Vector".  Maybe it does work on current existing
systems, but it's too fragile.


        Stefan