Infinity does not work in Windows - case with r.hants and r.series.lwr about grass-addons

[neteler]

Not sure how relevant, but here are some similar cases/changes:

• OSGeo/grass@3157c21
• OSGeo/grass@e7a50f3 (https://trac.osgeo.org/grass/ticket/2343)

[hellik]

from https://trac.osgeo.org/grass/ticket/2343

Infinities are sufficiently rare that it probably doesn't matter how they're handled (e.g. r.mapcalc explicitly checks for division by zero, log(0) etc and returns null). If it's just a matter of writing float_to_string() and string_to_float() functions which deal with them correctly (and we know how to write them), it should be done.

[metzm]

In r.hants and r.series.lwr, the option range=0,inf is converted to fp numbers with atof() which behaves like strod(). From the strtod manual (man strtod): "An infinity is either "INF" or "INFINITY", disregarding case." and "CONFORMING TO: POSIX.1-2001, POSIX.1-2008, C99. strtod() was also described in C89." That is atof("inf") should return the fp representation of infinity as defined by IEEE standards.
I don't see a reason why range=0,inf should not work on MS Windows. A broken version of atof/strtod in the operating system?

[marisn]

I don't see a reason why range=0,inf should not work on MS Windows. A broken version of atof/strtod in the operating system?

There is a bug report for mingw: https://sourceforge.net/p/mingw-w64/bugs/501/

[metzm]

I don't see a reason why range=0,inf should not work on MS Windows. A broken version of atof/strtod in the operating system?

There is a bug report for mingw: https://sourceforge.net/p/mingw-w64/bugs/501/

Ah, that explains it.
As an alternative, using a very large number instead of inf should work, e.g. range=0,1.7e308.

[lucadelu]

Could we close this?
It seems not a problem related to the addons