unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Daniel Colascione" <dancol@dancol.org>
Cc: emacs-devel@gnu.org
Subject: Re: buffer.c/buffer.h:  How to add new buffer-local variables?
Date: Wed, 03 Apr 2019 20:43:49 +0300	[thread overview]
Message-ID: <83zhp7c7ca.fsf@gnu.org> (raw)
In-Reply-To: <06afad36f4467eea0bc1daea58be1281.squirrel@dancol.org>

> Date: Tue, 2 Apr 2019 11:46:22 -0700
> From: "Daniel Colascione" <dancol@dancol.org>
> Cc: "Daniel Colascione" <dancol@dancol.org>,
>  emacs-devel@gnu.org
> 
> > 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.

Thanks, I went with a smaller value, 2KB.  It should be good enough
for now, as the largest object is slightly below 1KB.

> 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.

Right.



  reply	other threads:[~2019-04-03 17:43 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30 23:19 buffer.c/buffer.h: How to add new buffer-local variables? Keith David Bershatsky
2019-03-31  2:37 ` Eli Zaretskii
2019-03-31  3:49   ` Eli Zaretskii
2019-03-31  9:42 ` Andreas Schwab
2019-03-31 10:06   ` Eli Zaretskii
2019-03-31 11:41     ` Andreas Schwab
2019-03-31 15:10       ` Eli Zaretskii
2019-04-02 16:18       ` Eli Zaretskii
2019-04-02 18:46         ` Daniel Colascione
2019-04-03 17:43           ` Eli Zaretskii [this message]
2019-03-31 12:22 ` Alan Mackenzie
  -- strict thread matches above, loose matches on Subject: below --
2019-03-31  9:03 Keith David Bershatsky
2019-03-31 16:32 Keith David Bershatsky
2019-03-31 20:02 ` Stefan Monnier
2019-04-01  7:43 Keith David Bershatsky
2019-04-04 18:57 Keith David Bershatsky
2019-04-04 19:29 ` Eli Zaretskii
2019-04-07  2:50 Keith David Bershatsky
2019-04-07 15:48 ` Eli Zaretskii
2019-04-08  5:23 ` Paul Eggert
2019-04-08  4:34 Keith David Bershatsky
2019-04-08  8:03 Keith David Bershatsky
2019-04-08  9:37 ` Eli Zaretskii
2019-04-08 15:04   ` Eli Zaretskii
2019-04-08 17:31   ` Andreas Schwab
2019-04-08 17:43     ` Eli Zaretskii
2019-04-08 18:33       ` Stefan Monnier
2019-04-08 20:07         ` Paul Eggert
2019-04-08 22:19           ` Michael Welsh Duggan
2019-04-08 23:06             ` Paul Eggert
2019-04-09  6:13               ` Eli Zaretskii
2019-04-09  0:40 Keith David Bershatsky
2019-04-09  0:48 Keith David Bershatsky
2019-04-09  3:49 Keith David Bershatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zhp7c7ca.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dancol@dancol.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).