[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8546: fix for Emacs pseudovector incompatibility with GCC 4.6.0
From: |
Stefan Monnier |
Subject: |
bug#8546: fix for Emacs pseudovector incompatibility with GCC 4.6.0 |
Date: |
Tue, 26 Apr 2011 09:46:11 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>> + {
>> + EMACS_UINT size;
>> + union {
>> + struct buffer *buffer;
>> + struct Lisp_Vector *vector;
>> + } next;
>> + };
>>
>> Why do you need to handle buffers specially here? That sounds wrong.
> Purely as a convenience. The code always uses the 'next' pointer as a
> struct buffer * (in alloc.c, buffer.c, data.c), or as a struct
> Lisp_Vector * (in alloc.c, fns.c). As an alternative, we could
Ah, that makes sense (and deserves a brief comment). Makes me wonder,
tho: why do we need the struct vectorlike_header?
IIUC the core part of your fix is to make all accesses to `size' use the
same type (i.e. Lisp_Vector), right? Or does the use of the struct
help somehow?
While I understand the problem you're trying to fix, I don't know the
details of the C standard in sufficient detail to know exactly where's
the boundary between safe and unsafe. And your patch should have
a comment next to the core part of the fix explaining which part is
important and needs to be preserved.
> I thought that the union made the code clearer and I know you
Yes, that's fine. It just seemed odd to single out buffers.
>> Why does Lisp_Subr need to be a special case (IIUC this applies to
>> XSETTYPED_PSEUDOVECTOR and TYPED_PSEUDOVECTORP as well).
> struct Lisp_Subr has a "size" field but no "next" field.
Ah, yes, that makes sense as well (and deserves another brief comment).
Stefan