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

[Glynn Clements]

Hamish wrote:

> > >> 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"?

"long long" is C99, but provided by some C89 compilers as an
extension. Any use must be conditionalised upon:

	#ifdef HAVE_LONG_LONG_INT

Any "long long" values need to be printed with "%lld" ("%llu" for
unsigned), which also needs to be conditionalised.

> I notice r.info uses unsigned long long + printf %llu
> Shall we standardize on that?

The main downside is that you can end up needing a lot of conditional
code.

> 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.

LFS has two parts: making off_t a 64-bit type, and redirecting I/O
functions to the 64-bit versions.

In order to make off_t a 64-bit type, there has to *be* a 64-bit type. 
But that type will exist regardless of whether LFS is enabled.

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

off_t should only be used for file offsets. There's no advantage of
using it as a general-purpose integer type, as you need to convert it
to a standard type for printing, so you still need to check for the
existence of "long long" to determine which type to convert it to.

-- 
Glynn Clements <glynn at gclements.plus.com>