Non-native byte order corrupts data

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a variable using a non-native byte order.
2. Assign data to the variable.
3. View the resulting file with ncdump.

I've posted a script to do steps (1) and (2) at:
    https://gist.github.com/rhattersley/6686093

What is the expected output? What do you see instead?
The data values for the variables declared with non-native byte order are 
scrambled.
It would be helpful if the Variable class would either:
 - ensure its own dtype was always native byte order,
 - or raise an exception if constructed with a non-native byte order.
Raising an exception might be preferable as it would then draw attention to the 
"endian" parameter in the constructor and the lack of support for byte order 
selection in the non-HDF-based format variants.

What version of the product are you using? On what operating system?
1.0.2 (with netCDF v4.1.1, on RHEL6 64bit)

Please provide any additional information below.

The underlying netCDF API always expects data in native byte order. But the 
Variable._put method always coerces incoming data to the Variable's dtype 
without ensuring its dtype has native byte order. See 
https://code.google.com/p/netcdf4-python/source/browse/trunk/netCDF4.pyx#3152

Original issue reported on code.google.com by rhatters...@gmail.com on 24 Sep 2013 at 3:13

[GoogleCodeExporter]

Thanks for the report - it's now fixed in SVN.  Byteswapping is done as needed. 
I don't raise an exception for NETCDF3 files, but swap to the native 
endian-ness if needed.  Variable.endian() also now returns 'native' for NETCDF3 
files, and an exception is raised if you try to create a variable with anything 
but endian='native' in a NETCDF3 file.

I'll modify your test program and add it to the test suite.

Thanks again, and let me know if this fix works for you.

Original comment by whitaker.jeffrey@gmail.com on 25 Sep 2013 at 2:06

[GoogleCodeExporter]

Thanks Jeff. The fix in SVN does the job nicely.

Original comment by rhatters...@gmail.com on 25 Sep 2013 at 8:21

[GoogleCodeExporter]

Original comment by whitaker.jeffrey@gmail.com on 26 Feb 2014 at 2:04

• Changed state: Fixed