From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 36431@debbugs.gnu.org
Subject: bug#36431: Crash in marker.c:337
Date: Wed, 03 Jul 2019 07:49:13 +0300 [thread overview]
Message-ID: <83lfxfd8om.fsf@gnu.org> (raw)
In-Reply-To: <jwvpnmsjh5i.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Tue, 02 Jul 2019 17:00:21 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: wl@gnu.org, 36431@debbugs.gnu.org
> Date: Tue, 02 Jul 2019 17:00:21 -0400
>
> > It says that (a) CODING->src_pos is the negative of the offset from
> > GPT of where the bytes are in the gap
>
> Yes, I think this is actually wrong.
You are right.
> E.e. decode_coding_gap does:
>
> coding->src_chars = chars;
> [...]
> coding->src_pos = -chars;
>
> so nowhere does it account for unspecified number of bytes between the
> beginning of the gap and the beginning of the source text.
> Here, `src_pos` is the offset from the end of the gap.
Yes, the clear evidence is in coding_set_source:
if (coding->src_pos < 0)
coding->source = BUF_GAP_END_ADDR (buf) + coding->src_pos_byte;
(Note that it actually only uses the byte offset's numerical value. I
couldn't find any place where it actually uses the character offset in
src_pos, it only checks its sign.)
> > As for why this was designed like that -- where else did you see
> > comments in Emacs that answer this kind of questions?
>
> There are such design comments at various places.
> Usually added after the fact, sometimes added as part of
> a commit-reversal to make sure someone else doesn't fall into the same
> trap ;-)
Interesting. Can you point me to a couple of such design comments?
> If CODING->src_object is a buffer, it must be the current buffer.
> In this case, if CODING->src_pos is positive, it is a position of
> the source text in the buffer, otherwise, the source text is in the
> - gap area of the buffer, and CODING->src_pos specifies the offset of
> - the text from GPT (which must be the same as PT). If this is the
> - same buffer as CODING->dst_object, CODING->src_pos must be
> - negative.
> + gap area of the buffer, and CODING->src_pos specifies the
> + offset of the text from the end of the gap (which must be at PT).
The "which must be at PT" part is ambiguous. I suggest to say
explicitly that the gap must be at PT (although decode-coding doesn't
really blindly assume that, as you can see from its calls to
move_gap_both).
> + If this is the same buffer as CODING->dst_object, CODING->src_pos must
> + be negative.
I don't see the condition of the same buffer in the code. What did I
miss?
> + When the text is taken from the gap, it can't be at the beginning of
> + the gap so that we can produce the decoded text at the beginning of
> + the gap: this way, as the output grows, the input shrinks, so we only
> + need to allocate enough space for `max(IN, OUT)` instead of `IN + OUT`.
I think this should also tell that decoding in this setup takes bytes
from encoded text at the end of the gap and inserts the decoded text
starting at PT, which is the same as the beginning of the gap.
Without saying that, the above paragraph might not be as clear as it
should be.
next prev parent reply other threads:[~2019-07-03 4:49 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
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 [this message]
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=83lfxfd8om.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=36431@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.