GNU bug report logs - #36431
Crash in marker.c:337

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wl <at> gnu.org, 36431 <at> debbugs.gnu.org
Subject: bug#36431: Crash in marker.c:337
Date: Tue, 02 Jul 2019 13:22:22 -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

Previous Next

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