Hi Hal and Or,
We are checking on this and will get back.
Thanks,
Boris
On 03/13/13 05:58, Or Gerlitz wrote:
On 13/03/2013 14:48, Hal Rosenstock wrote:
On 3/12/2013 3:36 PM, Boris Chiu wrote:
>--- a/src/dump.c
>+++ b/src/dump.c
>@@ -46,12 +46,24 @@
>
>void mad_dump_int(char *buf, int bufsz, void *val, int valsz)
>{
>+ /*
>+ * the val pointer passed to the dump routines are always 32 bit
>+ * integers for valsz <= 4 and 64 bit integer for the rest. It is
>never
>+ * uint8_t or uint16_t. This is because mad_decode_field always
>returns
>+ * the values as 32 bit integer even if they are 8 bit or 16 bit
>fields.
>+ */
> switch (valsz) {
> case 1:
>- snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff);
>+#if defined(_BIG_ENDIAN)
>+ val = ((uint8_t *)val) + 3;
>+#endif /* _BIG_ENDIAN */
I don't understand what's different about SPARC and PPC in terms of
this. These routines all work without this on PPC64 and PPC32.
Yep, agree, assuming the code works on other BE archs, we 1st and most
need to understand the problem before going to solutions.
Or.
At a minimum, should this be ifdef'd on something like both __sun and
__SVR4 rather than _BIG_ENDIAN ?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
