x-coordinate over/underflow when x11 window shrunk

I find it hard to care much about this. If you shrink the plot to almost nothing, the contents are uninterpretable. So? Don't do that.

As you note, there is a general problem detecting coordiniate underflow. This is largely because terminal coordinates are defined to be unsigned, but in order to calculate clipping you need the signed (negative) values of lines that run off the edge. In some places the terminal code casts the unsigned coordinate back to signed in order to detect this, but I am not surprised that there are places it doesn't happen. Still, unless this causes a real problem I think it's as you say a corner case that can be tolerated.

I agree that the wxt terminal should not crash when shrunk. But I can't reproduce the problem so other than suggesting that a minimum size be enforced I can't offer much help. Can you trap enough of a call chain to say where and why it crashed. Is it because a requested window size goes negative (or wraps around to huge unsigned positive)?

Not much time right now, but quickly. I printed out some info to determine it is this code hunk that is primarily executed, i.e., plot_lines():

Index: graphics.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/graphics.c,v
retrieving revision 1.531
diff -u -r1.531 graphics.c
--- graphics.c  22 Aug 2016 18:44:22 -0000  1.531
+++ graphics.c  23 Aug 2016 20:22:04 -0000
@@ -1012,8 +1012,10 @@
    switch (plot->points[i].type) {
    case INRANGE:{

+fprintf(stderr, "x=%f  y=%f\n", plot->points[i].x, plot->points[i].y);
        x = map_x(plot->points[i].x);
        y = map_y(plot->points[i].y);
+fprintf(stderr, "mapx=%d  mapy=%d\n", x, y);

        /* map_x or map_y can hit NaN during eval_link_function(), in which */
        /* case the coordinate value is garbage and undefined is TRUE.      */
@@ -1023,6 +1025,7 @@
            break;

        if (prev == INRANGE) {
+fprintf(stderr, "v 1\n");
            (*t->vector) (x, y);
        } else if (prev == OUTRANGE) {
            /* from outrange to inrange */

The x,y --> xmap,ymap (i.e., float to integer) is where the wild numbers for x are coming from.

I then did the following:

Index: axis.h
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/axis.h,v
retrieving revision 1.154
diff -u -r1.154 axis.h
--- axis.h  3 Aug 2016 04:22:18 -0000   1.154
+++ axis.h  23 Aug 2016 20:22:02 -0000
@@ -399,6 +399,7 @@

 /* Macros to map from user to terminal coordinates and back */
 #define AXIS_MAP(axis, variable)       \
+fprintf(stderr, "tl= %f, min=%f, ts=%f\n", axis_array[axis].term_lower, axis_array[axis].min, axis_array[axis].term_scale); \
   (int) ((axis_array[axis].term_lower)     \
     + ((variable) - axis_array[axis].min)  \
     * axis_array[axis].term_scale + 0.5)

to see exactly what is wrong in the formula and I'm consistently see

v 1
x=6.969697  y=0.633843
tl= -10.000000, min=214748013.800000, ts=2535.000000
tl= -1.000000, min=1170.000000, ts=2535.000000

It's that x min value in the struct axis that seems out of bound, whereas the y min value doesn't seem to do that.

All I have time for right now...

I still don't see why this is a problem worth fixing.
If you shrink the plot window down to nothing, then the plot won't fit. So?

I'm trying to understand this one in hopes that it leads to the WXT crash bug. (Looks like they aren't the same.) Crash bugs are definitely a concern. Not shrinking the window size is fine if one knows to not do that, but even then it is typically an inadvertent action that causes such a thing. For example, depending on the mouse pad, sometimes optical mice will peg to one end of the screen or another. If that happens when resizing a window, the window shrinks. Plus, who knows how else it might be possible to create this situation, say the user manually sets the plot size fairly small and then resizes the window?

Anyway, I know what is happening here now. I noticed that this error message was only appearing when shrinking the x axis so that it inverts, but not for y-axis:

fprintf(stderr, "plot_bounds.ytop = %d\n", plot_bounds.ytop);
fprintf(stderr, "plot_bounds.ybot = %d\n", plot_bounds.ybot);
    /* Sanity check. FIXME:  Stricter test? Fatal error? */
    if (plot_bounds.xright < plot_bounds.xleft
    ||  plot_bounds.ytop   < plot_bounds.ybot)
    int_warn(NO_CARET, "Terminal canvas area too small to hold plot."
            "\n\t    Check plot boundary and font sizes.");

I watched ytop and ybot, and the strangely inverted roles when I expected ytop < ybot. The reason is that preceding this hunk of code is

    /* EAM - FIXME
     * Notwithstanding all these fancy calculations, plot_bounds.ytop must always be above plot_bounds.ybot
     */
    if (plot_bounds.ytop < plot_bounds.ybot) {
    int i = plot_bounds.ytop;

    plot_bounds.ytop = plot_bounds.ybot;
    plot_bounds.ybot = i;
    FPRINTF((stderr,"boundary: Big problems! plot_bounds.ybot > plot_bounds.ytop\n"));
    }

So, there's a hunk of code to flip ytop/ybot if necessary to ensure proper order. But there is no such code for xright/xleft. That's why this is occuring. Perhaps the ybot/ytop should not be interchanged, but instead allow it too to cause a warning. Also, as the comment says, maybe a stricture test is in order...not a fatal test, but simply do not draw the plot. If there is no plot and a warning message, the user will figure out what the problem is.

I don't think this is related to the WXT bug.