[GRASS-dev] Re: [GRASS GIS] #22: Grass r.out.mat 64bit Matlab reading problem

[Glynn Clements]

GRASS GIS wrote:

> #22: Grass r.out.mat 64bit Matlab reading problem
> ----------------------+-----------------------------------------------------
>   Reporter:  alexice  |       Owner:  grass-dev at lists.osgeo.org
>       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 <glynn at gclements.plus.com>