[openib-general] [PATCH] diags/saquery: fix node_desc.description as string usages

[Sasha Khapyorsky]

On 17:06 Tue 31 Oct     , Michael S. Tsirkin wrote:
> Quoting r. Sasha Khapyorsky <sashak at voltaire.com>:
> > Subject: Re: [PATCH] diags/saquery: fix node_desc.description as string usages
> > 
> > On 15:46 Tue 31 Oct     , Michael S. Tsirkin wrote:
> > > Quoting r. Sasha Khapyorsky <sashak at voltaire.com>:
> > > > > > Look at this for example:
> > > > > > http://sourceware.org/ml/bug-glibc/2005-02/msg00123.html
> > > > > 
> > > > > Hmm, yea. Do you understand the answer there?
> > > > > Does not make sense to me ...
> > > > 
> > > > I less care about the answer, but more about valgrind output (btw
> > > > cannot see this with glibc-2.5) and similar "corner case" issues.
> > > 
> > > Well, I understand what you are saying, but whether a work-around is worth it
> > > depends on whether the issue is still relevant in distros in use today
> > 
> > as well as with VC++/unknown DDK version?
> 
> Again, should be fine according to VC++ docs.

Maybe, never seen.

> Whether there's a bug in this function, or some other function, is
> an open question but I don't really see why make an exception here.
> 
> > 
> > > - the
> > > message you quote is from 2005.  After all, you never know whether some other
> > > piece of code triggers a compiler bug in some rare case on some outdated distro.
> > 
> > Right, but this one is "known".
> > 
> > > Can you run valgrind on the simple test and check?
> > 
> > Yes, it was fine with glibc-2.5.
> > 
> > > In any case, I think we need a commment so we can clean this up
> > > sometime in the future.
> > 
> > IMO it is better to just truncate original buffer by putting '\0' at the
> > end and don't think too much about "possible impacts", but feel free to
> > submit the patch.
> 
> I would just use the %.*s precision and not worry - its probably fixed in all
> distros already.

Feel free to submit the patch. I don't want to spend time for this now
and for possible "compatibility issues" later.

Sasha