0.0 and negative values result in buffer overrun.
Remotion opened this issue · comments
May be errol3_dtoa() is not really supposed to support 0.0 and negative values and this need to be done on higher level but any way support for max buffer length would be nice to prevent such cases.
At most we can add an assertion. As you said, it's a low level facility and we don't have to prevent programming errors at runtime.
I've also observed that passing 0 to errol4_dtoa results in an infinite loop.
Are there other restrictions on values that can be passed in? Will other values close to 0 also result in infinite loops (or buffer overruns)?
Neither errol.h nor errol.c say anything about being "low level" or what that might mean for how they need to be called. I'd like to use this code, but it's pretty hard to do so when there is some unknown set of invariants that need to be satisfied in order to use it safely.
Are there other restrictions on values that can be passed in? Will other values close to 0 also result in infinite loops (or buffer overruns)? Neither errol.h nor errol.c say anything about being "low level" or what that might mean for how they need to be called.
The algorithm's valid inputs are positive finite double-precision floating point values. Let x be a variable of type double. fpclassify(x) should compare equal to FP_NORMAL or FP_SUBNORMAL, and signbit(x) is true.
I'd like to use this code, but it's pretty hard to do so when there is some unknown set of invariants that need to be satisfied in order to use it safely.
There are no other restrictions. By saying "low level," I mean it is the smallest building block of a floating-point formatting routine. The user who builds this routine enjoys full freedom to format NaN as nan, -0.0 as 0, and so on.