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 <[email protected]> http://www.jemarch.net GNU Project http://www.gnu.org
