General bug - No out of bounds checking on 3D coordinates

[Ethan A M. <merritt@u.washington.edu>]

I have encountered a nasty bug that has been around since forever.
It is not obvious to me what is the best way to deal with it.

The basic problem is that the 3D mapping routine map3d_xy() in util3d.c
stuffs its output into (unsigned int) terminal coordinates.
But it does so without ever checking that the results are positive numbers.  

This may also happen with 2D plots, but if so I haven't encountered it yet.

Most of the terminal drivers simply clip the resulting absurd values,
so the error goes unnoticed.  But the pdf driver does not, and it would
be messy to do so. The illegal values are passed into routines
in libpdf, which prints an error message and then calls exit().

How should we deal with this?

- Have map3d_xy() call int_error() if the coordinates go negative?

- Have map3d_xy() siliently truncate to zero?

- Have map3d_xy() truncate, but not so silently?

- Change map3d_xy() to return floating point numbers, and have the
  caller deal with testing for negative values and then converting into
  unsigned ints afterward?

- Continue to return unsigned ints but make map3d_xy type 
  (int) rather than (void), and require that the calling routine check for
  error status in the return code?

- Leave map3d_xy() alone, and deal with it driver-by-driver, if needed?
  In the case of pdf.trm this would mean testing all coordinates passed
  to the driver.

My inclination is to silently truncate to zero, but because this is not
real clipping it can cause strange-looking output plots (extra junk
piles up along the bottom and left edge).

The cleanest is probably to return an error from map3d_xy, but since
there are roughly 100 call sites this would be a *lot* of extra code to
handle error checking.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle