From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: buffer.c/buffer.h: How to add new buffer-local variables? Date: Tue, 2 Apr 2019 11:46:22 -0700 Message-ID: <06afad36f4467eea0bc1daea58be1281.squirrel@dancol.org> References: <5A3C6A89-2360-46CF-8049-828A4B955445@gnu.org> <875zrzclts.fsf@igel.home> <83imvwfkik.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="269155"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , emacs-devel@gnu.org To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 02 20:47:28 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 1hBORT-0017tJ-Mf for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 20:47:28 +0200 Original-Received: from localhost ([127.0.0.1]:34747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBORS-000731-Ni for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 14:47:26 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBOQe-00072T-Gg for emacs-devel@gnu.org; Tue, 02 Apr 2019 14:46:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBOQd-0003nJ-D9 for emacs-devel@gnu.org; Tue, 02 Apr 2019 14:46:36 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:44554) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBOQb-0003Z0-2y; Tue, 02 Apr 2019 14:46:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=GuYJx5GQHDZ8M86pIWYJbYYl+Y80X6G85Nm30pH2RY0=; b=VROT4LHaNYWwk4+kgwOiveLO7PGcnt4PSbwWiFz13T0dnfgO/6vNu1GKc1NpkWUciVGRQkdghyAOlyPrma712ZipugWJgF2WZbxiop4+h86VbjAd3o/huKwfU34lreXeJxIzfpzBWQeRVWz6wRRE5D3ujmyFomOpmAaf2TtXaJ8UukR5USUVNtJc4Tg42dGfcks5vkIHZeHq1upu9alGZy5ZTf15WCGPSyggJtxcUO3GNSInJC+kO7349niXbi/IjwhKubnSiivwbZ6ikFP0DPPZ5yoZvUwcJ62PLwCQOG3uKxuZBmtFnLy1hlspZGT9mSLElqnaR6qb8uZUHYXYkw==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBOQQ-0005vs-AG; Tue, 02 Apr 2019 11:46:22 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Tue, 2 Apr 2019 11:46:22 -0700 In-Reply-To: <83imvwfkik.fsf@gnu.org> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:234888 Archived-At: >> From: Andreas Schwab >> Date: Sun, 31 Mar 2019 13:41:51 +0200 >> Cc: Keith David Bershatsky , emacs-devel@gnu.org >> >> On Mär 31 2019, Eli Zaretskii wrote: >> >> > So you are saying that the 1024 value is arbitrary and should be >> enlarged when more local vars are added? >> >> No. > > Daniel, could you please help me understand why the value 1024 was > used here: > > static dump_off > field_relpos (const void *in_start, const void *in_field) > { > ptrdiff_t in_start_val = (ptrdiff_t) in_start; > ptrdiff_t in_field_val = (ptrdiff_t) in_field; > eassert (in_start_val <= in_field_val); > ptrdiff_t relpos = in_field_val - in_start_val; > eassert (relpos < 1024); /* Sanity check. */ <<<<<<<<<<<< > return (dump_off) relpos; > } > > The comment says "sanity check", but I would like to understand what > kind of sanity is being checked here, and what should be done when > some structure we dump becomes larger than this value. E.g., is there > some other limit that requires that offsets of dumped fields never > exceed 1024 here? I'd like to document in comments what to do when > the assertion is violated. Indeed. That comment could have been a lot better. The general idea here is this: When we enter field_relpos, we're in the middle of some code that's dumping some data structure field-by-field. The object that we're dumping begins at in_start; and in_field is an interior pointer into that object. We can't actually check that the two pointers refer to the same object: C doesn't give us that level of introspection. But if the two pointers point to addresses that differ by a lot, then the two pointers probably don't refer to the same object, and in this case, we can fail an assertion. 1024 is probably too conservative here. We probably want to greatly increase this number (say, to 32k) and also to give it a named constantly, maybe something like PDUMPER_MAXIMUM_STRUCT_SIZE. Note that this limit doesn't apply to big variable-length structures like vectors: we dump these element-by-element instead of treating the whole thing as one big "object" with a large and variable number of fields.