Re: [PATCH] osm_subnet.c

[Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html