[GRASS-dev] Unlimited precision

GRASS GIS GRASS GIS developer
1

On Sun, 2007-10-21 at 23:05 +0200, Francesco P. Lovergine wrote:

http://www.nabble.com/ISO-C90-does-not-support-`long-long'-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.

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

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

2

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-`long-long'-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@gclements.plus.com>

3

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-`long-long'-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>

4

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@gclements.plus.com>

5

On Mon, Oct 22, 2007 at 05:08:31AM +0100, Glynn Clements wrote:

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

gcc supports as extensions both C89 and C++ long long. It is supported
in ISO C99. I see the range issue remains possibly unfixed in case of
other compilers. Not that I was so interested in it... :stuck_out_tongue:
Of course, someone should check if reduced ranges are incorrectly
used in other cases around...

--
Francesco P. Lovergine