GNU bug report logs - #8546
fix for Emacs pseudovector incompatibility with GCC 4.6.0

Previous Next

Full log

Message #20 received at 8546 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8546 <at> debbugs.gnu.org
Subject: Re: bug#8546: fix for Emacs pseudovector incompatibility with GCC
	4.6.0
Date: Tue, 26 Apr 2011 09:46:11 -0300

>> +  {
>> +    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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.