From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36431@debbugs.gnu.org
Subject: bug#36431: Crash in marker.c:337
Date: Tue, 02 Jul 2019 13:22:22 -0400 [thread overview]
Message-ID: <jwvpnmsjqsy.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <jwv1rz8la8z.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Tue, 02 Jul 2019 13:04:38 -0400")
> In the current code, we read the raw bytes to the beginning of the gap,
> then (when Vset_auto_coding_function needs to be called), we (virtually)
> move them into the current buffer, which is usually multibyte.
> AFAICT at this point we have a buffer in a transiently inconsistent
> state since it's multibyte but it can contain arbitrary byte sequences,
> hence invalid byte sequences. Before calling Vset_auto_coding_function
> we make this buffer unibyte, which brings us back to a consistent state,
> but I wonder if/how/why making the buffer unibyte and then back to
> multibyte always preserves the original byte sequence, since AFAICT
> set-buffer-multibyte will always make the effort to bring the buffer to
> a consistent state, so if the state is inconsistent before the pair of
> calls to set-buffer-multibyte, either we changed the byte sequence or
> set-buffer-multibyte doesn't always result in a consistent state.
> What am I missing?
OK, I finally saw that we don't actually call set-buffer-multibyte but
instead we just set bset_enable_multibyte_characters. I'm beginning to
understand better.
Stefan
next prev parent reply other threads:[~2019-07-02 17:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 11:17 bug#36431: Crash in marker.c:337 Werner LEMBERG
2019-06-29 12:13 ` Eli Zaretskii
2019-06-29 12:20 ` Eli Zaretskii
2019-06-29 22:56 ` Stefan Monnier
2019-06-30 7:26 ` Werner LEMBERG
2019-06-30 13:14 ` Stefan Monnier
2019-07-02 16:29 ` Stefan Monnier
2019-06-30 14:52 ` Eli Zaretskii
2019-06-30 14:39 ` Eli Zaretskii
2019-06-30 14:59 ` Stefan Monnier
2019-06-30 15:16 ` Eli Zaretskii
2019-06-30 15:53 ` Stefan Monnier
2019-07-02 17:04 ` Stefan Monnier
2019-07-02 17:22 ` Stefan Monnier [this message]
2019-07-02 17:37 ` Stefan Monnier
2019-07-02 17:42 ` Eli Zaretskii
2019-07-02 17:55 ` Stefan Monnier
2019-07-02 17:39 ` Eli Zaretskii
2019-07-02 17:51 ` Stefan Monnier
2019-07-02 18:27 ` Eli Zaretskii
2019-07-02 19:44 ` Stefan Monnier
2019-07-02 20:15 ` Eli Zaretskii
2019-07-02 21:00 ` Stefan Monnier
2019-07-03 4:49 ` Eli Zaretskii
2019-07-03 16:19 ` Stefan Monnier
2019-07-03 16:33 ` Eli Zaretskii
2019-07-03 4:21 ` Stefan Monnier
2019-07-03 4:55 ` Eli Zaretskii
2019-07-03 6:20 ` Werner LEMBERG
2019-07-03 6:29 ` Eli Zaretskii
2019-07-03 6:46 ` Werner LEMBERG
2019-07-03 7:14 ` Eli Zaretskii
2019-07-03 16:08 ` Stefan Monnier
2019-07-09 21:04 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvpnmsjqsy.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=36431@debbugs.gnu.org \
--cc=eliz@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.