[GRASS-dev] configure: testing arch endian

[Hamish]

> r.in.mat and r.out.mat are littered with "sizeof(long) == 4"
> assumptions.

The MATv4 file format specifies this (IIRC, it's been a while now & I'd
have to look it up), at least for the header but I think for the arrays
as well. The file header specifies which endianness the data that
follows was written in, it allows either.

If there are int/TYPE_CELL operations which are making this assumption,
missing casts, or are likely to be promoted to something other than
expected then yes that's something to look into.

> Also, AFAICT, r.out.mat always writes the output in the
> system's byte-order,

as specified by the format, byte order used is recorded in the header,

> and r.in.mat just assumes that the file is in the system's byte-order
> (it checks, but doesn't do anything in the event of a mismatch).

In the event of a mismatch it triggers a warning that this is "TODO" and
the rest will likely not succeed. I prefer that to a G_fatal_error(), it
encourages help with debugging. It is likely that more of those warnings
are needed for other endian/64bit permutations. The situation is also
mentioned in the r.in.mat help page. I'd rather invest the time fixing
the problem vs. going to great lengths to add more elablorate tests to
provide "sorry," messages.


> Both of those programs need to be substantially re-written.

I welcome help. Bitwise operations are not my forte.
Anyone using r.*.mat on a G5? No one has complained so far, but if
anyone does have problems the code is commented re. the possible use
of uint32 and I've tried to leave breadcrumbs along the way.


[r.out.bin]
> If you change the semantics of that flag so that the absence of the -s
> switch means little-endian while the presence of the flag means
> big-endian, r.out.bin doesn't need to know the host's byte order, and
> a given r.out.bin command achieves the same result (file in big-endian
> format or file in little-endian format) regardless of the system's
> byte order.

mmph. don't make the confusion worse; change the flag's letter to
something else and loudly warn -s is superseded. Are you advocating that
the default mode should not write out in the native byte order?! Is that
really "expected behavior"? I would think it preferable to have -b and
-l flags to force big or little if you want them, otherwise go native.
(but -b is taken for BIL, "-l" should be avoided as it looks the same as
"-1" in some fonts, and -e,-E has issues for mingw32 people...?)

> As for backwards compatibility, making the default byte order (no -s
> flag) little-endian means that anyone using x86 (i.e. most users) will
> be unaffected.

that's pretty crap for the non x86 crowd (who are the ones most likely
to need that flag in the first place).

 
> IOW, I've yet to come across a situation which actually has a
> legitimate reason to know the system's byte order.

my feelings are: seamless at the user end is good. ambiguity is bad.

> BTW, when it comes to floating-point values, the situation isn't as
> simple as big- or little-endian. On some systems, FP values may use a
> different byte order to integers, or double-precision FP values may
> have the 32-bit halves in a different order than the order of bytes
> within a word.

fun fun fun


Hamish