#1392 Another line clipping regression

[dima]

Here's a regression very similar to the recently-closed https://sourceforge.net/p/gnuplot/bugs/1390/ . However this issue was created by a much earlier revision:

https://github.com/gnuplot/gnuplot/commit/0fac1ec52137b4bf9dbd081e48a4600e2f6debc0

A demo script:

 set timefmt '%s'
 set xdata time

 set xrange [ "1398327639" : "1398327700" ]
 set yrange [ -1.50000 : 2.50000 ]

 set xtics
 plot '-'  using 1:2:3 with xerrorbars
 1398316828.81002 -0.1 3.70307302474976
 1398318635.55653 -1.1 1803.04344153404
 1398320685.85958 -0.1 3.67168343067169
 1398322191.52654 -1.1 1501.99527347088
 1398324137.0131 -0.1 3.62012648582458
 1398325643.01251 -1.1 1502.37928497791
 1398327659.25372 -0.1 3.23069858551025
 1398350853.84544 -1.1 23191.3610285521

This is a bunch of horizontal error bars. The long bar at the right sometimes isn't drawn.

[Ethan Merritt]

I now believe that the underlying cause of both this bug and the previous clipping bug #1390 is not any recent change in the higher level graphics routines. Instead the problem is that the standard clipping algorithm in gadgets.c (clip_line) was written under the assumption of infinite precision arithmetic. What is happening to us is that the expression (A*B >= 0) is used as an overly-clever test for "A is the same sign as B". It fails when A*B overflows.

The same thing bit us in bug #1358.
I'll fix the clip_line(), but it would be worth auditing the entire code base to make sure this same problem doesn't lurk elsewhere.