bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

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