Error in netcdf-4 endianness handling?

[DennisHeimbigner]

The attached file appears to produce incorrect result.
I believe this is because endianness is attached to the type
object (NC_TYPE_INFO_T) rather than the var object (NC_VAR_INFO_T).
In the attached, we define an enum type and use it as the var type
for two different variables. We then set different endianness on the
two variables. What happens is that the endianness of the first variable
is changed when the endianness of the second variable is set.
t_endian.zip

[DennisHeimbigner]

Note that the simplest (and maybe only) solution is to change
our documentation to restrict setting endianness only on
integer or float typed variables.

[DennisHeimbigner]

Apparently the integer/float restriction is already in the documentation,
but not enforced properly.

[DennisHeimbigner]

I also notice that nc_test4 has a test in which the endianness is set for
a variable of compound type. This all seems inconsistent. We probably
need to decide on the rule.

[edhartnett]

The rule is, as documented, that endianness should be set only for numeric types, not user-defined types.

This is a restriction on user-defined types that few are likely to notice or care about. No one really wants to mess with endianness, now that every processor uses little-endian and netCDF-4 uses native endian by default.

@WardF if you have a way to assign issues to me, you can do that with this issue. I'll can fix it when I get back from vacation.