Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

> Date: Tue, 03 Jul 2012 23:25:26 -0700
> From: Paul Eggert <address@hidden>
> Cc: Dmitry Antipov <address@hidden>, address@hidden
> 
> On 06/30/2012 07:23 AM, Stefan Monnier wrote:
> > No, the problem is long lines.
> 
> There's also a problem even if lines are short.
> I ran Emacs without the patch, on files with
> only short lines, and attempted large horizontal
> scroll values (say, most-positive-fixnum minus 100).
> The screen would mess up.  Sometimes even after I
> scrolled back to the left margin, there would be scroll
> indicators in the left column.  Sometimes there would
> be stray characters on the screen.
> 
> To work around this I pushed a patch (trunk bzr 108856)
> that arbitrarily ceilings the hscroll value at 100000.

I'm quite sure this is the wrong fix, it just sweeps the problem under
the carpet.  My guess is that, when hscroll is close to INT_MAX, the
calculations in display_line, e.g. here:

  /* Move over display elements that are not visible because we are
     hscrolled.  This may stop at an x-position < IT->first_visible_x
     if the first glyph is partially visible or if we hit a line end.  */
  if (it->current_x < it->first_visible_x)
    {
      this_line_min_pos = row->start.pos;
      move_it_in_display_line_to (it, ZV, it->first_visible_x,
                                  MOVE_TO_POS | MOVE_TO_X);

and in move_it_in_display_line_to this calls, overflow, because these
calculations are done in pixels, not in character cells, and so
typically (for the default font) manipulate values that are 10 times
larger than the hscroll value.

So to fix this in the right place, we need to limit the pixel
coordinates, not the character cell coordinates.

Feel free to fix the problem that way, or leave it to me.  But
revision 108856 should be reverted.

Thanks.