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:51:30 -0400 [thread overview]
Message-ID: <jwvef38jpuj.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83v9wkcp3z.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Jul 2019 20:39:44 +0300")
>> We start by inserting the new bytes at the *beginning* of the gap, but
>> when we do the move_gap_both this moves those bytes to the *end* of the
>> gap (where decode_coding_gap expects them, apparently), so when we
>> decode we always have to move all the inserted bytes, right?
>
> Yes. This is so we don't need to know up front how many bytes will be
> read from the file.
OK, so IIUC:
- we insert the new bytes at the beginning of the gap, in order to have
room to grow if there are more bytes than expected, and also in case
there are fewer bytes than expected (in which case we'd otherwise
have to move the bytes we just read so they properly end at the end
of the gap).
- decode_coding_gap wants the new input bytes to be at the end of the
gap, so that we can put the decoded chars at the beginning of the gap
and as one grows the other shrinks, so we don't need space for "IN +
OUT" bytes but only for "OUT" bytes. Is that right (I'm trying to
find some comment or other evidence that this is the case, but
haven't found it yet).
IOW, it should be possible to optimize the common case by reading the
new bytes into the end of the gap to avoid moving everything in the
common case (if the number of bytes read is different from originally
expected, we'll have to do extra work, but for the common case where we
know the file size upfront and it doesn't change while we read it, this
will save us some work).
But the effort is probably not worth the trouble: a memmove of a few
gigabytes costs relatively little compared to the cost of actually
decoding those same gigabytes.
Stefan
next prev parent reply other threads:[~2019-07-02 17:51 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 [this message]
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=jwvef38jpuj.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.