Ethan A Merritt wrote:
>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?
>
Hmm. Are you referring to situations where, say, some zoom and viewing
angle is such that coordinates go negative? I would think that could
happen fairly often, no? And in some sense it really isn't an error, is it?
>- Have map3d_xy() siliently truncate to zero?
>
Don't like this one. map3d_xy() is more of a utility type routine, and
as such it shouldn't assume too much about the final manner in which the
data is used. Here is one case in point. The image stuff has the
option of varifying the whole grid us uniformly spaced. Move some of
the negative coordinates and it could possible mess up the routine.
Even though the final routine may never use those points, the routine
will think it is not a uniform grid.
>- Have map3d_xy() truncate, but not so silently?
>
How do you mean?
>- 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.
>
Can signed ints be passed back to avoid the use of floating point? I'd
prefer that the final routine using the numbers do the sanity check.
I'm wondering if, in fact, the pdf utility calls inside pdf.trm don't
already take care of that, and if one passed a negative coordinate into
the routines instead of a mangled unsigned coordinate it might know what
to do, e.g., truncate a line at the border.
Dan
|
