[gradsusr] big/little endian bug in OpenGrads v2.0.a9.oga.1 for 2-byte integers files

Henrique Barbosa hmjbarbosa at gmail.com
Thu May 19 14:58:39 EDT 2011


Dear all,

I was trying to read a single variable written as 2-byte signed integer in a
big endian file. Plain binary file, i.e. stream, with no header. Should be
really simple, but it was not. For handling this, I had my CTL as:

(...)
options big_endian
(...)
myvar 0 -1,40,2,-1 ** my variable
(...)

However, it did not work. The values were completely wrong. After a day
trying to understand what as going on, I decided to force 'little_endian' on
the CTL despite the file being big-endian... and it worked!! and I could
read the data.

However, USGS claims gtopo30 to be big_endian. To make sure,  I wrote a  F90
program to read it. I could only get the correct data inside the program if
I opened the file as big_endian. Therefore, as USGS and my program agree, I
believe the data is big_endian.

Therefore the problem should be in grads. I made a series of tests, writing
1-byte, 2-byte and 4-byte integer binary files, and 4-byte float files, for
both little and big endian types. The only problem I found was with 2-byte
integers. I think that it is a bug in grads, actually, OpenGrads
v2.0.a9.oga.1. The necessary data to reproduce the problem can be found
here:

<http://www.fap.if.usp.br/~hbarbosa/file_format.tgz>

Can some expert have a look in the source code? Arlindo? Jennifer? By the
way, I am on x86-64 machine, runing ubuntu 64bits and using
grads-2.0.a9.oga.1-bundle-x86_64-rhel5.5-linux-gnu.tar.gz.

Sincerely,
Henrique
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20110519/bc5eae1c/attachment-0003.html 


More information about the gradsusr mailing list