GRASS GIS wrote: > #22: Grass r.out.mat 64bit Matlab reading problem > ----------------------+----------------------------------------------------- > Reporter: alexice | Owner: [email protected] > Type: defect | Status: new > Priority: minor | Milestone: 6.3.0 > Component: default | Version: 6.2.3 > Resolution: | Keywords: > ----------------------+----------------------------------------------------- > Comment (by hamish): > > Glynn: > > The correct solution is to explicitly [de]serialise values rather > > than reading/writing the in-memory representation directly from/to > > files. > > If anyone wants to write a patch, feel free. > > 1grey: > > but won't the explicit [de]serialisation also solve endianness > > issues, if any? > > r.in|out.mat's endian code is in a only-just-working state. As the > endianness of the file's data is stored in one of the header bits I > propose we follow one of Glynn's earlier suggestions and just force > r.out.mat to always produce little endian output regardless of platform
Actually, I would suggest using big-endian format. That way, if someone writes code which ignores byte order (i.e. just read directly into memory), you discover it sooner rather than later. [On a related issue, the UK is at a disadvantage when it comes to writing code which deals with timezones. If you confuse GMT and local time, you won't notice until daylight-saving time starts.] -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
