[gdal-dev] +/-infinity as an uninitialized marker

[Even Rouault]

On mardi 21 mars 2017 07:50:34 CET Kurt Schwehr wrote:
> Hey Even,
> 
> Probably not a big deal, but I'm curious why you didn't use !isinf(MinX) or
> isfinite(MinX) for your recent OGREnvelope patch:
> 
> int  IsInit() const { return MinX !=
> std::numeric_limits<double>::infinity(); }
> 
> My only thought is that if something goes totally messy and it uses !isinf
> or isfinite, the code might retry initialization later when it's not going
> to get any better (if MinX ends up -inf or one of the NaNs)?  I'm pretty
> sure that infinity is always well behaved (unlike the crazy world of NaNs),
> so I can't see a case where your code would go wrong.

I've considered isinf() but I know we have had issues in some environments with isinf() being 
a macro, and thus std::isinf() ending up std::something_different
Actually, it seems std::isinf() is C++11 ?
http://en.cppreference.com/w/cpp/numeric/math/isinf

I could also have used CPLIsInf() instead.

But in both cases indeed if someone uses a legit envelope that would be minx=-inf,miny=-
inf,maxx=inf,maxy=inf, it would be considered as uninit.
I think equality comparison to std::numeric_limits<double>::infinity() should be fine, at least 
on IEEE754 compatible envs since there's a single binary representation for +inf.

If NaN values appear, then I think the whole class behaviour is pretty much undefined (as 
before my change)

> 
> As procrastination, I posted this overly wordy question on stack overflow
> as I didn't find a good match with 10 seconds of searching...
> 
> http://stackoverflow.com/questions/42930445/val-stdnumeric-limitsdoubleinfin
> ity-or-isinfval-or-isfiniteval
> 
> -kurt


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170321/8f4d2a35/attachment-0001.html>