[GRASS-dev] r.in.xyz: really big ints

[Glynn Clements]

Hamish wrote:

> line: at one point I use if(line % 10000 == 0), which I suspect would
> prefer ints over FPs, and I'd like to keep that.

The % operator doesn't work for FP; you can to use fmod() instead.

> G_alloc(rows*cols*sizeof(CELL)) is another thing, but unrelated to the
> filesize so a matter for another thread & time.

This isn't applicable to memory allocation. You can always fit the
size of a region of memory into a size_t. On Unix, it's safe to assume
that you will always be able to fit it into a "long".

> If I change int to long and %d to %ld, life gets better on 64bit machines
> but not 32bit machines -- they stay at 2^31-1.
> 
> If I use unsigned long int and %uld (does that exist?)

It's %lu. u is the unsigned version of d. u and d are specifiers, of
which you can only have one; l and ll are qualifiers, used in addition
to a specifier.

> would it mean we can have 2^32-1 on 32bits and 2^64-1 on 64bits?

Yes.

> re. running times, r.in.xyz processing will be directly proportional to
> the number of passes required. So it's not surprising that
> percent=50 (2 passes) is 10 times faster than percent=5 (20 passes).
> 
> I would not hold my breath for widespread 64bit MS Windows XP support
> from commercial vendors. It is hard to justify spending effort porting
> your drivers/software to a niche system which is already EOL'd, even if
> current users demand it. At the same time I think people are dragging
> their feet waiting to see what replaces Vista. (probably just a
> superficial PR name change in 2009 for SP2, but who knows for sure?)

64-bit Windows is problematic because of Windows' reliance upon binary
compatibility. Ever since the 80286 became obsolete, Windows has
revolved around the 80386 architecture; 32-bit, little-endian, with no
alignment requirements.

OTOH, Unix has traditionally focused on source compatibility (although
the recent dominance of x86 has resulted in portability getting less
attention than it used to). Making architecture-specific assumptions
(e.g. fwriting()ing "struct"s) tends to be treated as a bug.

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