[ofa-general] libibmad-1.6.1:_dump_fields() incorrect for big endian

[Joseph L Greathouse]

Hi there,

libibmad-1.1.6/src/dump.c:_dump_fields() does not always work correctly for
big endian machines.

Example:
'smpquery portinfo' to a Mellanox ConnectX from a big endian machine prints
a number of values incorrectly as zero.  (e.g.
RespTimeVal:.....................0, when RespTimeVal is actually 16)

>From what I can tell, this is an issue between how _get_field() is used in
mad_decode_field and how mad_dump_field uses functions like
mad_dump_uint........

mad.c:mad_decode_field() sets *(uint32_t *)val = _get_field(), while
_get_field() always returns a host-endian uint32_t of the value of the
field.  This means that on little endian machines, val[0] contains the
value of a byte-length field. On big endian machines, val[3] contains this
value.

mad_dump_field calls, for example, dump.c:mad_dump_uint(). This will check
the size (in rounded-up bytes) of the field. For a single byte, it will
print *(uint8_t *)val, which is val[0].  This works on little endian, but
prints zero on big endian.

Possible solution:
In the mad_dump_* functions, for cases 1, 2, 3, and 4 in the switch
statement, always print *(uint32_t *)val.  I believe the dump functions are
always fed by _get_field (or get_field64), and thus for values of size 1-4
bytes, any unused bytes will always be zeroed out by _get_field().

I don't want to go around writing patches or filing bug reports all
willy-nilly, so I thought it best to just report this and see if what I've
come up with makes sense. :)

-Joe