[GRASS-dev] Unlimited precision

[Glynn Clements]

Brad Douglas wrote:

> On Sun, 2007-10-21 at 23:05 +0200, Francesco P. Lovergine wrote:
> > http://www.nabble.com/ISO-C90-does-not-support-%60long-long%27-tf1038737.html#a2698581
> > 
> > About long long issue and other possible extension, I would promote the
> > use of GMP extended precision library, which is LGPL and largely used.
> > 
> > For instance it would be a nice solution for issues like:
> > 
> > http://wald.intevation.org/tracker/?func=detail&aid=493&group_id=21&atid=204
> > 
> > and indeed long long is already used in the code as you can see grepping
> > around.
> 
> I just committed a compiler test for 'long long' to configure.

I was working on that, and it caused a conflict. Comparing the two
versions, I reverted it and used mine instead. The differences are:

1. The current version uses AC_TRY_COMPILE; the previous version used
AC_TRY_RUN, which is unnecessary effort and won't work when
cross-compiling.

2. The current version uses HAVE_LONG_LONG_INT rather than
HAVE_LONG_LONG, as that is the name used by the AC_TYPE_LONG_LONG_INT
macro in more recent versions of autoconf.

> It defines HAVE_LONG_LONG macro (in include/config.h) so offending code
> can be segregated.
> 
> Affected code:
> - r.info
> - r.terraflow
> - g.region
> - lib/vector/dglib/type.h

I have fixed g.region. I also fixed the r.info fix:

1. The format specifier for unsigned int is %u; %d is signed.

2. "long long" values need %llu/%lld rather than %lu/%ld.

AFAICT, dglib and r.terraflow remain untouched. dglib is awkward
because the 64-bit values are part of the file format, so you can't
just use a 32-bit int if long long isn't available.

I'm not sure what the situation is with C++, i.e. whether "long long"
is part of the standard. If it isn't, we need another check; whether
the C compiler supports "long long" and whether the C++ compiler
supports it are separate issues.

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