On 10:16 Tue 14 Apr     , Hal Rosenstock wrote:
> On Tue, Apr 14, 2009 at 10:09 AM, Sasha Khapyorsky <[email protected]> 
> wrote:
> > On 09:42 Tue 14 Apr ?? ?? , Hal Rosenstock wrote:
> >>
> >> Signed-off-by: Hal Rosenstock <[email protected]>
> >>
> >> ---
> >> Changes from v1:
> >> In trap 144, display local changes as %u rather than %d
> >> In trap 256, don't use additional buffer and eliminate buffer copying
> >>
> >> diff --git a/opensm/opensm/osm_helper.c b/opensm/opensm/osm_helper.c
> >
> > [snip...]
> >
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? n += sprintf(buff + n, 
> >> "Directed Path Dump of %u hop path:"
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? "\n\t\t\t\tPath = 
> >> ",
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
> >> p_ntci->data_details.ntc_256.dr_trunc_hop & 0x3f);
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? for (i = 0;
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??i <= 
> >> (p_ntci->data_details.ntc_256.dr_trunc_hop & 0x3f);
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??i++) {
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (i == 0)
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
> >> sprintf(buff + n, "%d",
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
> >> ?? ?? p_ntci->data_details.ntc_256.dr_rtn_path[i]);
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? else
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
> >> sprintf(buff + n, ",%d",
> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
> >> ?? ?? p_ntci->data_details.ntc_256.dr_rtn_path[i]);
> >
> > Should be n += sprintf() in both cases.
> 
> Right.

And also "\n" at the end.

> > Also I would recommend to use
> > snprintf() instead of sprintf() to prevent possible buf overflow.
> 
> It doesn't overflow but I can change it.

If you know for sure. I will need to calculate all lengths including
cases when broken data is received - better to not think about this and
to not rely on hardcoded buffer size.

> Also, there are many other
> places even in this file where this is not done.

This is likely true, but why to add new potentially buggy things.

Sasha
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to