CLAMP does not handle NaN correctly
Hi all,
While fixing a crash I noticed that the CLAMP macro does not handle NaN properly, although it is stated in its comments that it should ("returns v bounded to within [a, b]. If v is NaN then returns a."). Apparently, if NaN goes in, then NaN comes out :-(.
I tried fixing this in the macro but I didn't succeed. Could one of the little-less-inexperienced devs have a look at this? This crash can be reproduced using revision 21793 or older: create a grid, draw a star, and snap both its handles to the same grid intersection. So far so good. Now try drawing a new star somewhere else and watch in horror! The "proportion" parameter of the star has become NaN, and remains NaN although it has been clamped in sp_star_context_set().
If I use this line for debugging (inserted on line 210 of star-context.cpp)
std::cout << "CLAMP DOESN'T HANDLE NaN! Before clamping: " << val->getDouble(0.5) << " -> after clamping: " << sc->proportion << std::endl;
Then this is what I get:
CLAMP DOESN'T HANDLE NaN! Before clamping: nan -> after clamping: nan
I fixed this for the star but there might be more instances of this bug. It might however save us some future headaches if someone could fix the CLAMP macro.
Regards,
Diederik
Could it be that it's using the glib version of CLAMP, I wonder? The macro in src/libnr/nr-macros.h looks correct.
We might need to rename to NR_CLAMP. I'm just trying a build with that change now.
pjrm.
I've changed libnr/nr-macros.h to prefer our version of CLAMP over glib's, and I've changed both sp-star.cpp and star-context.cpp to call NR_CLAMP explicitly, but I haven't been able to test here.
Diederik, can you svn up and test please?
Thanks,
pjrm.
On 07/13/2009 05:26 AM, Peter Moulder wrote:
I've changed libnr/nr-macros.h to prefer our version of CLAMP over glib's, and I've changed both sp-star.cpp and star-context.cpp to call NR_CLAMP explicitly, but I haven't been able to test here.
Diederik, can you svn up and test please?
Thanks for looking into this, this indeed fixed the issue!
Can we now safely replace all occurrences of CLAMP with NR_CLAMP, with the v0.47 release being this close? Or should we be safe and wait until after the release?
Regards,
Diederik
participants (2)
-
Diederik van Lierop
-
Peter Moulder