[Bug] `r.stats` reports negative counts when tabulating across 2 rasters

[adamlilith]

Describe the bug

r.stats outputs negative counts when tabulating cell counts across two CELL rasters. Counts should always be >0. The issue seems to happen when rasters are large... I cannot find any other pattern in the rasters that creates this issue (it works as expected for small rasters).

To reproduce

Here are the two rasters: https://drive.google.com/drive/folders/1g9PdUt9kVbfVNvSL5GdTSU2O8MsJ0yLy?usp=sharing
I will remove these from this link when the issue is resolved.

Procedure (assume we have created a new project using one of the rasters as a template for the CRS):

r.in.gdal input=C:\se_asia\PREMASK_countries_rast.tif output=countries
r.in.gdal input=C:\se_asia\PREMASK_pas_rast.tif output=pas
r.stats -c -n -N input=countries@PERMANENT,pas@PERMANENT seperator=comma format=plain

Output:

0 | 1 | 147127241
0 | 2 | -1547225620
0 | 3 | 254269816
0 | 4 | 255460477
0 | 5 | 869781375
0 | 6 | 519965947
0 | 7 | 388394838
1 | 1 | 94864167
1 | 2 | 76723442
1 | 3 | 1766537
1 | 4 | 59398797
1 | 5 | 63054109
1 | 6 | 128309551
1 | 7 | 58242020

Notice the negative count on line 2.

Expected behavior

Counts should always be >= 0.

System description

• Operating System: Windows 11 Home 25H2
• GRASS version: As shown here, using 8.5 but 8.4 has same issue
• details about further software components
  System Info
  GRASS version: 8.5.0
  Code revision: exported
  Build date: 2026-06-12
  Build platform: x86_64-w64-mingw32
  GDAL: 3.13.1
  PROJ: 9.8.1
  GEOS: 3.14.1
  SQLite: 3.53.2
  Python: 3.12.13
  wxPython: 4.2.5
  Platform: Windows-11-10.0.26200-SP0 (OSGeo4W)
• Python and wxPython:
  3.12.13 (main, Jul 10 2026, 00:56:33) [MSC v.1944 64 bit (AMD64)]
  4.2.5 msw (phoenix) wxWidgets 3.2.9

[adamlilith]

Same issue occurs using r.stats on just the first raster by itself to get cell counts. Counts are negative for cells that equal 2 (in the example output above).

[marisn]

How many cells are in both rasters? It seems that r.stats internally uses int's to store some counts and there is an overflow – a bump to larger counter could fix that.

[adamlilith]

That may be it--they are 105063 x 74530, so 7830345390 cells.

[marisn]

That's it! The code used long to store counts – fine on Linux, but on Windows that is too short.