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

[Dmitry Antipov]

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