From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: buffer.c/buffer.h: How to add new buffer-local variables? Date: Mon, 08 Apr 2019 18:04:28 +0300 Message-ID: <83a7h08rnn.fsf@gnu.org> References: <3C6817C0-1CDB-4F83-805E-BF6B93C77F44@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="183107"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: esq@lawlist.com, eggert@cs.ucla.edu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 08 17:04:53 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDVpM-000lUa-JF for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 17:04:52 +0200 Original-Received: from localhost ([127.0.0.1]:54432 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDVpL-000304-HC for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 11:04:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDVp6-0002wQ-AQ for emacs-devel@gnu.org; Mon, 08 Apr 2019 11:04:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDVp5-0004NX-Fn; Mon, 08 Apr 2019 11:04:35 -0400 Original-Received: from [176.228.60.248] (port=3916 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hDVp3-0007j2-NZ; Mon, 08 Apr 2019 11:04:34 -0400 In-reply-to: <3C6817C0-1CDB-4F83-805E-BF6B93C77F44@gnu.org> (message from Eli Zaretskii on Mon, 08 Apr 2019 12:37:57 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235116 Archived-At: > Date: Mon, 08 Apr 2019 12:37:57 +0300 > From: Eli Zaretskii > Cc: acm@muc.de, dancol@dancol.org, schwab@linux-m68k.org, > monnier@iro.umontreal.ca > > The problem is caused by the 4-byte hole between the last Lisp_Object member of the buffer structure and the beginning of struct buffer_text. It causes us to decide that a buffer has 83 Lisp components, whereas it actually has only 82. The hole is left uninitialized, and causes the segfault when we try to use it as a valid object. To clarify, I meant this hole: > /* 324 | 4 */ Lisp_Object extra_line_spacing_; > /* 328 | 4 */ Lisp_Object cursor_in_non_selected_windows_; > /* XXX 4-byte hole */ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > /* 336 | 104 */ struct buffer_text { > /* 336 | 4 */ unsigned char *beg; Significantly, it doesn't show in what Paul saw in a 32-bit Fedora build. I guess the MS-Windows port of GCC has some special rules in this case, perhaps triggered by the fact that some members of 'struct buffer_text' are now 64-bit integers, and perhaps GCC on Windows wants them 8-byte aligned? > I guess we need to make BUFFER_LISP_SIZE smarter? Not sure how, though. Perhaps we should simply make BUFFER_LISP_SIZE a literal number and request whoever extends 'struct buffer' to keep that in sync manually?