Problem writing big-endian data to existing file

[neishm]

Writing big-endian data into an existing netCDF4 (on a little-endian system) does not seem to properly swap the bytes.

The following example from Unidata/netcdf4-python#1033 (comment) triggers the problem:

#include <netcdf.h>
int main() {
    int i, iret, dimid, varid, ncid;
    int data[10];
    for (i = 0; i < 10; i++)
        data[i] = i;
    iret = nc_create("test.nc", NC_NETCDF4, &ncid);
    iret = nc_def_dim(ncid, "x", 10, &dimid);
    iret = nc_def_var(ncid, "v", NC_INT, 1, &dimid, &varid);
    iret = nc_def_var_endian(ncid, varid, NC_ENDIAN_BIG);
    /*iret = nc_put_var_int(ncid, varid, data);*/
    iret = nc_close(ncid);
    iret = nc_open("test.nc", NC_WRITE, &ncid);
    iret = nc_put_var_int(ncid, varid, data);
    iret = nc_close(ncid);
}

The resulting file has the data:

 v = 0, 16777216, 33554432, 50331648, 67108864, 83886080, 100663296, 
    117440512, 134217728, 150994944 ;

where the values should be 0,1,2,3,4,5,6,7,8,9. This was tested with netcdf version 4.7.3 on an Ubuntu 20.04 system, and also the latest development snapshot (b9bb44f) was tested with the same result.

If the intermediate nc_close and nc_open calls are commented out (i.e. still writing into a new file), then the data is written correctly.

[WardF]

So recreating this, I am relieved that it doesn't appear the issue is storing the data, but rather in how ncdump is printing it. I am investigating further.

[WardF]

Ok, still sorting through this, making a comment so it does not shuffle down the stack. I'm seeing largely consistent behavior between BE and LE systems, but I have found some differences. I need to sort out the intent (endianness in memory vs. in storage) so I know which behavior is expected. Work is ongoing (on this and so many other things O_o).