bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36431: Crash in marker.c:337


From: Eli Zaretskii
Subject: bug#36431: Crash in marker.c:337
Date: Tue, 02 Jul 2019 23:15:45 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Tue, 02 Jul 2019 15:44:07 -0400
> 
>     Decode the data at CODING->src_object into CODING->dst_object.
>     CODING->src_object is a buffer, a string, or nil.
>     CODING->dst_object is a buffer.
>  
>     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.
>  [...]
>     The decoded data is inserted at the current point of the buffer
>     CODING->dst_object.
> 
> but this doesn't say if the bytes are to be found originally at the
> beginning of the gap or its end, nor whether they finish at the beginning or
> the end, nor what happens in the middle and why it's been designed this way.

It says that (a) CODING->src_pos is the negative of the offset from
GPT of where the bytes are in the gap (they don't have to be "at the
end", AFAIU, just not "at the beginning"); and (b) that the decoded
text is inserted at point.  And those are, AFAIK, the only real
conditions, all the rest is not necessary, it's just what's
convenient.

As for why this was designed like that -- where else did you see
comments in Emacs that answer this kind of questions?

> Is the patch below correct?

I think it describes conditions that don't need to exist.

> I think the crash-example I sent can probably be made less esoteric by
> making it use "quit" instead of catch/throw.  I'm beginning to think
> that when we quit (or signal an error) from within
> set-auto-coding-function, we simply shouldn't revert the buffer
> to multibyte.

We have code whose purpose is to recover from such calamities, so if
it doesn't do its job in all cases, we need to augment it.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]