Hamish wrote:
> suggest to use 'unsigned long' and "%lu" as is done by r.in.xyz,
> and 'off_t' for 'n_alloc'.
There is no point in using anything larger than size_t for n_alloc.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.or
On 11/09/2011 23:26, Hamish wrote:
try r48240 in trunk.
I downloaded grass7 from trunk and its r.univar now reports for the same
map I used earlier:
> total null and non-null cells: 271400 (rather than -1580967296)
Thanks for the fix. Will it also find its way into version 6.4.2?
He
Markus wrote:
> I can confirm this (64bit Linux):
>
> GRASS 6.4.2svn (nc_spm_08):~ > g.region -dg res=8
...
> GRASS 6.4.2svn (nc_spm_08):~ > r.univar elevation
> 100%
> total null and non-null cells: -347311046
> total null cells: -350476046
...
> I suppose that r.univar is lacking the
On Tue, Aug 23, 2011 at 8:48 AM, Hermann Peifer wrote:
> Hi,
>
> r.univar gives me negative cell counts, whereas r.stats -c produces correct
> results (I hope ;-):
>
> (...)
> 41 118441
> 42 193
> 43 135
> 44 8189
> * 2704177984
>
> I guess this is the same integer overflow issue reported earlier
Hi,
r.univar gives me negative cell counts, whereas r.stats -c produces
correct results (I hope ;-):
(...)
41 118441
42 193
43 135
44 8189
* 2704177984
I guess this is the same integer overflow issue reported earlier [1]. I
am just a bit puzzled that after changing to a 64-bit Linux OS, resu
