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

[Dmitry Antipov <dmantipov@yandex.ru>]

On 07/02/2014 06:30 PM, Stefan Monnier wrote:

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

Strictly speaking, you're right. ISO C99 says (6.7.2.1) just:

"Each non-bit-field member of a structure or union object is aligned in an
implementation-defined manner appropriate to its type."

In fact, on a 64-bit system and 32-bit system with --with-wide-int, sizeof (int) is
4 and sizeof (Lisp_Object) is 8. On a 64-bit system, any reasonable compiler should
pack 2 integers to 8-byte area, so SUB_CHAR_TABLE_OFFSET is 1; if the compiler is
stupid and packs each field to 8-byte slot, SUB_CHAR_TABLE_OFFSET is 2. On a 32-bit
system, SUB_CHAR_TABLE_OFFSET is 2 if sizeof (Lisp_Object) is 4 and 1 if
sizeof(Lisp_Object) is 8; anyway, it should be aligned (unless some packing tricks
are in effect?)

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

I'll install verify() to catch future (broken) systems.

Dmitry