[GRASS-dev] Re: [GRASS-user] r.stats: negative cell counts and percentages

[Hamish]

Hermann wrote:
> svn up https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 grass64_release

not that it matters here, but do you use 32 bit or 64 bit
CPU+OS?
 
> (on 8 Sptember 2009)
...
> >> I have the following raster map:
> >> 
> >> Type of Map:  raster     
>         Number of Categories: 255 Data
> Type:    CELL    Rows:   
>     58000     Columns: 
>     67000       Total
> Cells:  3886000000
> >> 
> >> r.stats (-c and -p) tells me:
...
> >> I guess there is an integer overflow somewhere(?)

Yeah, I think you are right.

There are many int++'s in raster/r.stats/stats.c
Perhaps those counters++ should be changed to "long long"?


what is the result of r.univar ?

I see r.univar has been modified to use int for number of cells
and number of non-null cells. (earlier versions used unsigned
int, why the change?) But 'unsigned int' for the counter just
postpones the problem a couple of years, maybe long long is
better there?

Like r.info, I think r.univar and r.stats are pretty fundamental
raster modules to have working correctly for this.


#32bit linux system/gcc
sizeof(long long) is 8
sizeof(long)      is 4
sizeof(int)       is 4

#64bit linux system/gcc
sizeof(long long) is 8
sizeof(long)      is 8
sizeof(int)       is 4


I notice r.info uses unsigned long long + printf %llu
Shall we standardize on that? If it can be done without
dealing with --enable-lfs all the better, I'm pretty sure
that LFS has more to do with which 64bit friendly glibc
functions to use so not relevant. But I'm not 100% sure
about this stuff so I ask.


I'm guessing that off_t should only be used for addresses,
or if all else fails can it be repurposed?


Hamish