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

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Mon, 5 Jul 2004, Daniel J Sebald wrote:
>
>  
>
>>I don't understand why negative coordinates is an error.  Conceptually, 
>>it's as though our view port is from (0, 0) to (x_max, y_max). 
>> Certainly there are some situations where the graphical element may 
>>make no sense to be outside that range.  But the decision if that is a 
>>problem or not lies at the very last use, inside the driver.
>>    
>>
>
>Not really.  The terminal driver can only do what I would refer to as
>"emergency clipping".  I.e. if a point passed to the driver is outside the
>viewport, but the output format can't handle that, the gnuplot terminal
>driver will have to deal with that, probably by discarding the entire
>primitive being drawn.
>

I agree with that.  That's sort of what I was driving at before.

>  That appears to be the case for our PDF driver.
>

I tried a hack test to not cast from unsigned int (variable defined) to 
float (PDF_xxx() argument), but rather treat it as signed.  It seemed to 
work.  So perhaps no extra code will be needed to discard primitives if 
we are lucky.

>[On a side note:]
>  
>
>>There is one thing about the terminal scheme that 
>>doesn't have a solid concept, or at least I don't recognize it.  It is 
>>how to have "default" routines of a driver.  
>>    
>>
>
>That's what the do_whatever() routines in term.c are for.  For functions
>that are required, a driver can register those directly.  It can even
>just supply a zero (i.e. a NULL function pointer) and change_term() will
>fill in the right default handler.
>

Ah.  I've looked at the term.c file in passing but it never registered 
with me.

>Unfortunately the NULL pointer replacement aspect of this scheme is only
>good for one level of inheritance, i.e. there's a single, somewhat virtual
>"base" terminal driver, using only the fallback routines, and a given
>driver can either use those, or implement its own overrides.   For doing
>real inheritance, we have to refer to what in C++ parlance would be
>caused "mangled" method names, e.g. in epslatex.trm, which registers
>the postscript driver's PM3D functions to itself, turning itself into
>something of a derived class of post.trm.  
>

Right.

Dan

>  
>