r3.info segfaults or reports incorrect values on Windows

[annakrat]

When I run r3.info on Windows on a map computed with v.vol.rst, it's segfaults and stops writing output after:

 |        Projection: Lambert Conformal Conic (zone 0)
 |            N:        100    S:          0   Res:     1
 |            E:        100    W:          0   Res:     1

When I create a random map:

g.region w=0 e=100 s=0 n=100 t=100 b=0 res=1 res3=1
r3.mapcalc "test = rand(0,100)"

it doesn't segfault but I get nonsense (I guess it's the same problem):

|        Projection: Lambert Conformal Conic (zone 0)
|            N:        100    S:          0   Res:     1
|            E:        100    W:          0   Res:     1
|            T:          0    B:          0   Res:     0
|   Range of data:   min =          0 max =          0

The same map copied to linux has no problems. Perhaps the function format_double could cause it since it is used for reporting top, bottom and range values.

Further investigation shows that r.info reports wrong number of categories (0) on a map which has categories. This would again point at format_double function which looks completely the same as in r3.info. However, v.info seems to work although it uses again format_double function, but slightly modified:

r(3).info:

void format_double(const double value, char *buf)
{
    sprintf(buf, "%.8lf", value);
    G_trim_decimal(buf);
}

v.info:

void format_double(double value, char *buf)
{
    sprintf(buf, "%.8f", value);
    G_trim_decimal(buf);
}

Could the l in the formatting make difference on Windows?

[wenzeslaus]

I seems that some C standards allow l to precede f but they also say that lf is the same as f. From this it seems that on MS Windows, because of MinGW or whatever, lf have unpredictable behavior. So, since it is not different form f (both mean double), I suggest to replace all occurrences of lf by f.

Also, the fact that there is more than format_double() function tells me that it should be moved to the library. It might also avoid possibility of bugs like this. The function looks pretty general, or at least, it is used generally. Or do you think that these small functions should not go to the library?

[annakrat]

I removed the l from the function in r3.info module to test if it makes difference (r61172).

[annakrat]

Replying to annakrat:

I removed the l from the function in r3.info module to test if it makes difference (r61172).

This fixed the problem. I applied it to r.info (r61189) and backported to releasebranch (r61190) .

[neteler]

Milestone renamed