[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] trunk r117464: Shrink Lisp_Sub_Char_Table by preferrin

From: Dmitry Antipov
Subject: Re: [Emacs-diffs] trunk r117464: Shrink Lisp_Sub_Char_Table by preferring C integers to Lisp_Objects.
Date: Wed, 02 Jul 2014 19:13:24 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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 ( 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 
pack 2 integers to 8-byte area, so SUB_CHAR_TABLE_OFFSET is 1; if the compiler 
stupid and packs each field to 8-byte slot, SUB_CHAR_TABLE_OFFSET is 2. On a 
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 
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]