[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36431: Crash in marker.c:337
From: |
Stefan Monnier |
Subject: |
bug#36431: Crash in marker.c:337 |
Date: |
Wed, 03 Jul 2019 12:19:22 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> (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
- bug#36431: Crash in marker.c:337, (continued)
bug#36431: Crash in marker.c:337, Eli Zaretskii, 2019/07/02
- bug#36431: Crash in marker.c:337, Stefan Monnier, 2019/07/02
- bug#36431: Crash in marker.c:337, Eli Zaretskii, 2019/07/02
- bug#36431: Crash in marker.c:337, Stefan Monnier, 2019/07/02
- bug#36431: Crash in marker.c:337, Eli Zaretskii, 2019/07/02
- bug#36431: Crash in marker.c:337, Stefan Monnier, 2019/07/02
- bug#36431: Crash in marker.c:337, Eli Zaretskii, 2019/07/03
- bug#36431: Crash in marker.c:337,
Stefan Monnier <=
- bug#36431: Crash in marker.c:337, Eli Zaretskii, 2019/07/03
bug#36431: Crash in marker.c:337, Stefan Monnier, 2019/07/03
bug#36431: Crash in marker.c:337, Stefan Monnier, 2019/07/03
bug#36431: Crash in marker.c:337, Stefan Monnier, 2019/07/09