#1396 Another line-clipping issue

[dima]

Hi. Thanks for fixing the previous line-clipping issues (bugs 1358, 1390 and 1392). I just found another problematic case:

set terminal x11 noenhanced
set ytics format "%7.3f"
set xlabel  "Time(s)"
set timefmt '%s'
set xdata time
set format x "%m/%d\n%H:%M"
set xtics
set xdata time
set xrange [ "999999996" : "999999999" ]
set yrange [ -4.15925 : 32.1324 ]
plot '-' using 1:2:3 with xerrorbars
998999999.000002 -0.1 999999
1000000003 -1.1 5.00000303983688
e

As before, the horizontal error bar on the left is missing.

[Ethan Merritt]

In the earlier bugs the clipping code itself introduced an integer overflow. This could be fixed by correcting the clipping code.

This example is not quite the same. Here the error bar extends so far out of the plot that its X coordinate overflows integer representation even before clipping. This is sensitive to the resolution of the current terminal coordinate system. For instance, if you do "set term dumb" instead of "set term x11" the plot will display correctly because the dumb terminal is only 80x24 "pixels".

Other than switching to 64-bit integers everywhere in the code, I'm not certain how best to address this one. On some platforms there may be a compiler option to throw an error on integer overflow, but that's not common. Not to mention that having a single missing line on the plot is much less annoying that having the program fail with an overflow error message.

Possibly the code paths that map input coordinates (floating point) to terminal coordinates (integer) could check for overflow. I am uncertain how many different places in the code would be affected. I am also uncertain what the error path would be.

[Ethan Merritt]

Slight correction:

The x coordinate overflows for the fist point itself
point at: (020000000000 01572)

Given that the point itself is so far out of range, I'm not sure failing to draw part of its error bar rises to the level of "bug".