Re: [pdf-devel] Type 4 & implementation limits

[jemarch]

Hi Johannes.

   I have some questions regarding type 4 functions and implementation
   limits. The specifiction says that an error must be raised if an
   operation tries to exceed an implementation limit, so I assume the
   same holds true for type 4 functions.

Right.  The general rule applies there.

   I have seen some macros for library specific limits (PDF_I32_MAX,
   no MIN defined yet), should those limits also be used for the type
   4 floating point return values or should floating point specific
   limits be defined? If so I would also recommend to add some special
   value that can be returned by the pdf_fp_* functions to signal an
   over-/underflow, something similar to HUGE_VAL in libc.

Agreed.  Maximum/minimum should be defined in pdf-fp.h, as well as a
not-a-number value and checker.  The idea is to encapsulate the
underlying floating-point implementation in pdf-fp.[ch].

Since there are systems not supporting NaN for floats, would be good
to use the 'isnan' module from gnulib.

   The specification also explicitely allows that intermediate results of 
   type 4 functions do not fall under the implementation limit restrictions.
   It would be possible to allow larger values for intermediate results, 
   as we are calculating with doubles but returning pdf_real_t (float). Is
   this desirable?

There is nothing wrong in using double values for intermediate
calculations, but an explicit double->pdf_real_t conversion function
is in order, in my opinion.  We should not rely in implicit casts.

   If so, against which limits should the intermediate results be
   checked then? Against libc's limits?

Seems reasonable, but in that case the limits may differ from system
to system.

Of course an alternative would be to use pdf_real_t values for the
intermediate calculations in pdf-fp-func.[ch].

-- 
Jose E. Marchesi  <address@hidden>
                  http://www.jemarch.net
GNU Project       http://www.gnu.org