[GRASS-dev] Unlimited precision

[Glynn Clements]

Brad Douglas wrote:

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

AC_TRY_CPP, AC_TRY_COMPILE and AC_TRY_LINK all 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.
> 
> 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.

If it was a "free" choice, I would have skipped the _INT, but it's
less effort if we eventually move to a more recent version 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.
> 
> AFAIK, there is no C++ standard for 64-bit integrals.  Bad news for
> r.terraflow.

Comments in the g++ headers suggest that "long long" is a GNU
extension. Technically, we should really have another compilation
check, but I strongly suspect that if the C and C++ compilers aren't
"matched", we'll have bigger problems than just "long long".

> Anyone get a response on the non-GPL status of it?

Not yet.

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