GNU bug report logs -
#56683
29.0.50; long lines fix doesn't work correctly when lines are truncated
Previous Next
Full log
Message #62 received at 56683 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>
> Yes, integer overflow. This code:
>
> init_to_row_start (&it, w, cursor_row);
> if (hscl)
> it.first_visible_x = window_hscroll_limited (w, it.f)
> * FRAME_COLUMN_WIDTH (it.f);
> it.last_visible_x = DISP_INFINITY;
> move_it_in_display_line_to (&it, pt, -1, MOVE_TO_POS);
>
> 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.
Se that being said, what I orignally wanted to ask, was:
>> The thing you implemented in set_iterator_to_next we talked about.
>>
>> 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.
This bug report was last modified 2 years and 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.