On 09:09 Mon 05 Oct , Smith, Stan wrote: > >> > >> --- a/opensm/opensm/osm_subnet.c 2009-10-01 > >> 12:45:52.000000000 -0700 +++ b/opensm/opensm/osm_subnet.c > >> 2009-10-01 14:24:18.000000000 -0700 @@ -397,7 +397,7 @@ > >> > >> /********************************************************************** > >> > >> **********************************************************************/ > >> -static long compar_mgids(const void *m1, const void *m2) +static > >> intn_t compar_mgids(const void *m1, const void *m2) > > > > Any disagreement about changing a prototype of this method > > (cl_pfn_fmap_cmp_t) in complib to use standard type (long) instead of > > "homemade" and less clear one ('intn_t')? > > > > Sasha > > > >> { > >> return memcmp(m1, m2, sizeof(ib_gid_t)); > >> } > > How is the processor architecture 'natural' size intn_t less clear than > 'long'?
'intn_t' is not a standard type, but a hack defined in complib, unlike this 'long' is a very basic C language type (btw I'm fine with 'int' for this particular case). > In some worlds sizeof(long) != sizeof(void*). This is bad. Fortunately for this case we don't need a "natural" int. And for case where it is really needed a standard types would be more appropriate in general than complib's defined intn_t. Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html