Ticket #636 (new defect)

Opened 3 years ago

Last modified 3 years ago

localmag and gmew (others?) incorrectly presume SAC files are always SPARC byte order

Reported by: baker Owned by: somebody
Priority: minor Milestone: All Platforms
Component: ALL modules Version: 7.9
Keywords: SAC Cc:


src/seismic_processing/gmew/gm_sac.c and src/seismic_processing/localmag/lm_sac.c unconditionally byte swap SAC files when _INTEL is defined, i.e., on little-endian hardware. The code is prefixed by the comment:

    /* SAC files are always in "_SPARC" byte order; swap if necessary */

This presumption is wrong; SAC files are no longer always "_SPARC" byte order. There may be other instances of the same presumption whenever SAC files are read/written.

It is not clear anyone uses these modules to read/write SAC files, since it would be obvious that something was wrong if they did.

Change History

comment:1 Changed 3 years ago by paulf

Hi Larry,

There are a few utilities out there to swap sac byte order to what is expected by the program you are trying to use the format with. Even the SAC software itself comes with something called "sacswap" to get the job done...ergo folks may still use the SAC output of localmag or gmew to inspect the Wood Anderson sesimograms or the ground motion seismograms that were created, but know enough to make the files readable for the SAC utility they are using.

To be honest, I don't know what the correct byte ordering is for a SAC file and would have to research that. Thanks for pointing out this issue.



Note: See TracTickets for help on using tickets.