[GRASS-dev] Re: sizeof(long) + nviz on reclass map [was: RC5 on Mac OS X]

[Hamish]

Helena wrote:
> can you please test one additional nviz issue?
> 
> with nc_spm_08 data set, what happens when you run
> 
> g.region rast=elevation
> nviz elevation col=landclass96
> 
> this used to run, but now I get:
> 
> Warning: loading failed
> ERROR:
> 
> landclass96 is a reclass raster, making it regular raster, fixes the
> problem.
> It used to run, so I am not sure whether there is a problem with my
> data set or with my version of GRASS (I am using William's
> grass64 binary).


I can see the same thing on linux 64bit.


The warning is because Gs_loadmap_as_char() in lib/ogsf/Gs3.c returns -2,
which apparently means:
   \return -2 if read ok, but 1 or more values
   were too large (small) to fit into an unsigned char.
   (in which case the max (min) char is used)
.... 
    return (overflow ? -2 : 1);
}


... which points to a 32bit/64bit sizeof() snafu ..

Indeed, lib/ogsf/ makes extensive use of "long".

grass65/lib/ogsf$ grep -w long * | wc -l
58


a small C program:
#include <stdio.h>

int main()
{
   printf("sizeof(int) = %d\n", sizeof(int));
   printf("sizeof(long) = %d\n", sizeof(long));
   printf("sizeof(long long) = %d\n", sizeof(long long));
   printf("sizeof(float) = %d\n", sizeof(float));
   printf("sizeof(double) = %d\n", sizeof(double));

   return 0;
}


on 32bit i686 linux + gcc:
 sizeof(int) = 4
 sizeof(long) = 4
 sizeof(long long) = 8
 sizeof(float) = 4
 sizeof(double) = 8

on 64bit amd64 linux + gcc:
 sizeof(int) = 4
 sizeof(long) = 8
 sizeof(long long) = 8
 sizeof(float) = 4
 sizeof(double) = 8



which would be a great theory if it worked on 32bit linux, but of
course it crashes there too, so dunno.


Hamish