***SPAM*** Re: [ofa-general] ***SPAM*** Re: [PATCHv2] opensm/osm_helper.c: Add more info for traps 144 and 256-259 in osm_dump_notice

Sasha Khapyorsky sashak at voltaire.com
Tue Apr 14 07:30:23 PDT 2009


On 10:16 Tue 14 Apr     , Hal Rosenstock wrote:
> On Tue, Apr 14, 2009 at 10:09 AM, Sasha Khapyorsky <sashak at voltaire.com> wrote:
> > On 09:42 Tue 14 Apr ?? ?? , Hal Rosenstock wrote:
> >>
> >> Signed-off-by: Hal Rosenstock <hal.rosenstock at gmail.com>
> >>
> >> ---
> >> 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



More information about the general mailing list