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: Wed, 03 Jul 2019 19:33:22 +0300	[thread overview]
Message-ID: <83o92baxil.fsf@gnu.org> (raw)
In-Reply-To: <jwvftnnhzfx.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Wed, 03 Jul 2019 12:19:22 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: wl@gnu.org,  36431@debbugs.gnu.org
> Date: Wed, 03 Jul 2019 12:19:22 -0400
> 
> > (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.

My point was that the code uses the sign of one of them and the value
of the other.

> >> +   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.

The text could be interpreted as meaning that the end of the gap must
be at PT.  IOW, "which" could either allude to the gap or to the end
of the gap.

> > (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 assumed that you wanted to clarify the comment, so preserving old
text sounds like a non-goal ;-)

> 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.

No, I meant the code there actually tests these conditions, and if
they are not true, it moves the gap as needed to make them true.

> >> +   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.

I don't think it's true.  CODING->src_pos must be negative if the
source text is in the gap, period.

> >> +   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 ;-)  ]

Not in what I wrote, AFAICT.





  reply	other threads:[~2019-07-03 16:33 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
2019-07-03 16:33                           ` Eli Zaretskii [this message]
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=83o92baxil.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.