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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user