[GRASS-dev] [GRASS GIS] #1500: g.region returns wrong convergence angle

#1500: g.region returns wrong convergence angle
---------------------------------+-----------------------------------
  Reporter: annakrat | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: major | Milestone: 6.4.6
Component: Projections/Datums | Version: svn-trunk
Resolution: | Keywords: g.region, convergence
       CPU: Unspecified | Platform: Unspecified
---------------------------------+-----------------------------------

Comment (by olly):

I suspect the bug here is due to `fact` not being initialised here:

https://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/printwindow.c#L488

I'd try changing that line to:

{{{
#!c
struct FACTORS fact = { 0 };
}}}

Or zero it out with `memset()` if you prefer.

If this function is called with previously unused stack space, you'll
probably get "lucky" and `fact` will be zero initialised (which explains
why hamish failed to reproduce this), but if the stack has been previously
used, you'll get arbitrary values there, and likely different ones for
each call.

I'm not a grass developer, or even a grass user, so I've not attempted to
test this change in grass itself.

I'm actually just trying to calculate convergence using PROJ.4 in my own
code. That's much harder than it ought to be due to the `pj_factors()`
function not being in `proj_api.h`. Reading past discussion of that led
me to this code in grass.

However testing the same approach in my code gave incorrect convergence
values, and different ones for the same input coordinates and projection.
Running under valgrind showed uninitialised data being used inside
libproj. I have no debug symbols to hand for that so I couldn't see
exactly where, but zero initialising the `struct FACTORS` cured the
valgrind errors, and consistently gives me the correct convergence, so it
seems `pj_factors()` expects that.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1500#comment:6&gt;
GRASS GIS <https://grass.osgeo.org>