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: Wed, 03 Jul 2019 12:19:22 -0400 [thread overview]
Message-ID: <jwvftnnhzfx.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83lfxfd8om.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Jul 2019 07:49:13 +0300")
> (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.)
The source is required to be unibyte, so src_pos and src_pos_byte have
to be equal at start and one of the two is redundant.
>> 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?
Not off-hand, no, but I know I added such comments every once in a while.
>> 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
AFAICT that's exactly what it is saying, so I'm not sure what ambiguity
you're thinking of.
> (although decode-coding doesn't really blindly assume that, as you can
> see from its calls to move_gap_both).
[ FWIW, this part of the text is mostly preserved from the old text. ]
I think the issue is that decode_coding's calls to move_gap_both *must*
be no-ops when the source is in the gap otherwise it'll destroy the
source-text.
>> + 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?
This one I don't know: I just preserved this part of the text.
>> + 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.
[ PT is both the beginning and the end of the gap ;-) ]
OK, I'll clarify a bit, thanks.
Stefan
next prev parent reply other threads:[~2019-07-03 16:19 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
2019-07-03 16:19 ` Stefan Monnier [this message]
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=jwvftnnhzfx.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.