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 tried a hack test to not cast from unsigned int (variable defined) to 
>>float (PDF_xxx() argument), but rather treat it as signed.  
>>    
>>
>
>I'm a bit uneasy about that change, as described, but that may be because
>the description has been a bit vague.  Please note you may absolutely
>*not* change the signatures of the terminal API entry point functions from
>unsigned int to int.  That would cause undefined behaviour.  What you do
>at the interface layer between pdf.trm and libpdf doesn't matter, as long
>as it improves things, but the interface between pdf.trm and the rest of
>gnuplot should be considered cast in stone.
>
>Could you please mail me (or the list) that patch for inspection?
>

No patch.  I called it a hack test because it was never intended to be 
used.  It was simply a quick and dirty way of testing whether the PDF 
driver could handle negative numbers as coordinates (as opposed to the 
outrageously large wrapped number), which appears to be the case.  I 
think in most C compilers a cast from a signed to unsigned or vice-versa 
doesn't change the value of the variable in memory, it simply changes 
how the variable is interpretted by the compiler when it used.  So, the 
number passes all the way to the driver level and it is only when 
changed to a float as an argument to the PDF_xxx() routines that it is 
interpretted.

I think Ethan's point at the last email was just what you are saying, 
addressing the signed/unsigned issue is a major alteration and would 
have to wait a bit.

Dan