suggestion: disallowing users to change endianness and validating data when using `write` method

[ehgus]

Current write method convert data endianness by looking at header.machst
https://github.com/sethaxen/MRC.jl/blob/ccce338315ff59d90872f3d21a813bf4347986ea/src/io.jl#L93-L107
This looks unsafe because user manually can change header.machst to decide its store endianness format.
My suggestion is that users is meant to be not allowed to change its endianness manually and write method do validation check to prevent such manual changes.

I'd like to change the code this way if you like this alternative.

[sethaxen]

This is actually this way by design. MRC is first and foremost an I/O package. For header.machst, this enables the user to write the MRC file with a different endianness than they read it in as. Here's an example using http://ftp.rcsb.org/pub/emdb/structures/EMD-5778/map/emd_5778.map.gz:

using MRC

emdid = 5778 # TRPV1
fn = "emd_$(emdid).map.gz"
fn2 = "emd_$(emdid)_2.map.gz"
dmap = read(fn, MRCData)
print(dmap.header.machst) # (0x44, 0x41, 0x00, 0x00)

# change endianness
dmap.header.machst = Tuple(MRC.MACHINE_STAMP_BIG)
print(dmap.header.machst) # (0x11, 0x11, 0x00, 0x00)
write(fn2, dmap)

# check that files use different endianness
read(fn)[end-100:end] == read(fn2)[end-100:end] # false

# check that read-in data is the same
dmap2 = read(fn2, MRCData)
dmap == dmap2 # true

Granted, I don't have a reason to write a file with a different endianness, but perhaps some user might.

[ehgus]

Thank you for you answer! I was a little confused of how to use ti, but it's clear now.