On Tue, 2012-05-15 at 10:02 -0600, Rao Garimella wrote:
> Hi
>
> I am using the Exodus II software based on NetCDF for a large project
> and have tracked down errors with some compilers and some platforms to a
> line where the code is trying to retrieve values using
> nc_get_var_longlong. It should retrieve a value of 1 for a variable
> named eb_prop but I get 3562469840667017217. I have listed some of the
> results of my debugging this problem
>
> 1. The developer of the Exodus II software tells me that many of his
> users have used his software with the latest NetCDF with no problems.
>
> 2. For us, this happens with gcc on Ubunutu Linux on a 32-bit machine
> and with the Intel compilers on Ubuntu Linux on 32-bit and 64-bit
> machines. Other people in our project have reproduced this error on a
> Fedora machine and on some supercomputers with the intel compiler.
>
> 3. So it seems that perhaps there is a mismatch between the
> understanding of 'long long int' between NetCDF and the calling code?
>
> 4. Digging a little further I see that swapn4b is picking up a 1 but
> 'swapping' bytes around and generating this large number (BUT PERHAPS I
> WENT DOWN THE WRONG RABBIT HOLE).
>
> 5. I also noticed that the configure script for NetCDF complains that
> longlong and uchar are undeclared (and indeed longlong is undeclared
> while 'long long' is valid).
>
> 6. When I do an 'ncdump' of the file being read, it shows me that
> eb_prop has a value of 1 as expected.
>
> If you have any ideas on what might be wrong please let me know. I did
> not include the config.log or the NetCDF file here to avoid overloading
> the initial description of the problem but I can do it if required.
>
> Thanks
> Rao Garimella
> Los Alamos National Laboratory
I wonder if ncx_getn_int_longlong should call swapn8b instead of swapn4b
since long long variables are 8 bytes long! (Thanks Cedric Roux for the
hint). It seems that only 4 bytes are being inserted into the return
variables instead of 8 bytes. If the receiving variables are not
properly initialized, then the first four bytes have garbage and the
last four bytes have the value read from the file. This might explain
why this error crops up on only with some platform and compiler
combinations.
