From: Hans-Bernhard B. <br...@ph...> - 2005-08-17 18:05:07
|
Ethan Merritt wrote: > Yes. It's really a nightmare. Although you raise a possible > issue below, my inclination is that we should never be using > unsigned coordinates. Wrapping around to a large positive number > is far worse than going negative. Not really. It's the same problem in a different dress. Terminal coordinates are really only valid in some interval. That interval always has one endpoint at zero, by design, so it makes sense for the coordinates to be unsigned. It being unsigned even helps generate faster code: a single test for (x < term->xmax) will detect points that are off to the right or the left. Any case of a coordinate outside that range being passed to the driver is a bug in the core: it's a clear sign that somebody forgot to do proper clipping. An extension to the debug.trm that checks each and every coordinate passed to it (plus options that let you change the sizes it reports to the core) might be in order, to ease testing of such things a bit. >>And try to remember that we have at least some drivers >>where >> >> INT_MAX < term->xmax < UINT_MAX. > > > Are you sure? Which ones? All the 16-bit platforms easily have this potential, 32-bit ones can be driven there. Win16 always is close to behaving like that by default during copy-to-clipboard (24000x18000 pixels). Many others, including postscript, can be made to, if you only 'set size' high enough before 'set term' or use the driver's own 'size' option. |