test case bin3 failed in my x86_64 box

[Stone, Joshua I]

On Thursday, April 27, 2006 12:29 PM, Frank Ch. Eigler wrote:
> Anyway, having explicit endian-conversion functions like those doesn't
> make much sense to me.  Endianness is really an external
> representation (serialization) issue only, which would be naturally
> expressed as modified formatting options for binary printf.

Martin and I discussed this - one of the ideas I had was to (ab)use the
formatting flags as follows:

     %b = native cpu order
    %-b = little-endian
    %+b = big-endian / network order

It is unlikely that one would want to mix endian types within a script,
so it seems a bit cleaner to have a single set_endian function that can
be called once from the begin probe.  This is simply a semantic decision
-- it should be a pretty minimal change to have the formatting flags
control endianness instead of a global flag.

However, note that a global flag also allows tapsets to ignore endian
issues.  For example, you could have a function
"print_binary_stacktrace" that makes no claims about endianness, so
whatever the user defined with set_endian will prevail.


Josh