[GRASS-dev] Unlimited precision

[Brad Douglas]

On Mon, 2007-10-22 at 00:50 +0100, Glynn Clements wrote:
> 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.

I knew I had a cross-compiling issue, but didn't know AC_TRY_COMPILE can
correct it.

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

I originally used HAVE_LONG_LONG_INT, but figured HAVE_LONG_LONG would
suffice.  'long long' implies int.  Doesn't hurt to be verbose, though.

Thanks for committing a better version of the test.

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

AFAIK, there is no C++ standard for 64-bit integrals.  Bad news for
r.terraflow.  Anyone get a response on the non-GPL status of it?


-- 
73, de Brad KB8UYR/6 <rez touchofmadness com>