[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are
From: |
Gerd Möllmann |
Subject: |
bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated |
Date: |
Fri, 22 Jul 2022 14:56:22 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@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.
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Andrey Listopadov, 2022/07/21
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gregory Heytings, 2022/07/21
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/21
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gregory Heytings, 2022/07/21
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gerd Möllmann, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gerd Möllmann, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated,
Gerd Möllmann <=
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gerd Möllmann, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gregory Heytings, 2022/07/25
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Andrey Listopadov, 2022/07/26
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gregory Heytings, 2022/07/26
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/26
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/26
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gregory Heytings, 2022/07/26
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/26