bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: andreyorst@gmail.com,  56683@debbugs.gnu.org,  gregory@heytings.org
> Date: Fri, 22 Jul 2022 14:56:22 +0200
> 
> > will keep producing glyphs inside move_it_in_display_line_to until
> > it gets to the position of point.  While producing glyphs,
> > it.current_x is incremented by the pixel-width of each produced
> > glyph.  After a large enough number of produced glyphs, it.current_x
> > will overflow INT_MAX.
> 
> Right.  I am not worried about that:
> 
> It takes a lot of iterations until the ints overflow.  The largest
> positive 32-bit integer is very roughly 2 * 10^9.  With a font width of
> of 10 pixels, that would mean 2 * 10^8 characters (200 Mb), and so on
> with wider fonts.

We already have an example of a 19-MB file which is a single line.  It
is within an order of magnitude of the limit you described.  JSON
files in particular are known to be like that: long and without
newlines.

So I think the danger is real.

> >>   if (max_redisplay_ticks > 0)
> >>     update_redisplay_ticks (1, it->w);
> >
> > I understood that part, but not the "should be burn to much time
> > because of the infinite last x" part, even if I replace "to" with
> > "too".
> 
> Sorry for the typo: s/be/we, i.e. "if we burn...".  What I meant to ask
> is if the check above doesn't lead to a signal anyway long before we
> reach the overflow.

That feature is disabled by default.  If enabled, then yes, it will
most probably fire before that.