all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Tue, 02 Jul 2019 23:15:45 +0300	[thread overview]
Message-ID: <83pnmschvy.fsf@gnu.org> (raw)
In-Reply-To: <jwvr278i6ap.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Tue, 02 Jul 2019 15:44:07 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: wl@gnu.org,  36431@debbugs.gnu.org
> 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	other threads:[~2019-07-02 20:15 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 [this message]
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=83pnmschvy.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.