[GRASS-dev] Re: [GRASS-user] r.stats: negative cell counts and
glynn at gclements.plus.com
Thu Oct 1 13:50:14 EDT 2009
> > >> 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:
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
> 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>
More information about the grass-dev