<br><tt><font size=2>Eric Blake <eblake@redhat.com> wrote on 04/01/2010
01:20:30 PM:<br>
<br>
</font></tt>
<br><tt><font size=2>> <br>
> On 03/31/2010 02:45 PM, Stefan Berger wrote:<br>
> > @@ -433,9 +430,10 @@ macProtocolIDFormatter(virBufferPtr buf,<br>
> >                  
      nwf->p.ethHdrFilter.dataProtocolID.u.u16,<br>
> >                  
      &str)) {<br>
> >          virBufferVSprintf(buf, "%s",
str);<br>
> > -        return 1;<br>
> > +    } else {<br>
> > +        virBufferVSprintf(buf, "%d",
<br>
> nwf->p.ethHdrFilter.dataProtocolID.u.u16);<br>
> <br>
> This would look a bit better as %u than %d, to match the fact that
we<br>
> know it is unsigned, but at least I don't see any problems with sign<br>
> extension biting us if we leave the line alone.<br>
> <br>
> > +                  
         if (virStrToLong_i(prop, NULL, 10, <br>
> &int_val) == 0) {<br>
> > +                  
             if (int_val >= 0 &&
int_val <= 32) {<br>
> <br>
> Is it any more efficient to use virStrToLong_ui, so that you can drop<br>
> the int_val>=0 half of the test by virtue of the fact that you
parsed an<br>
> unsigned int to begin with?</font></tt>
<br>
<br><tt><font size=2>Well, I could introduce a uint_val variable. I actually
had tried that _ui function yesterday but then the signed problem came
up with the int_val and thought that this probably boils down to 2 more
assembly instructions and left it as it is... Also it's not in a critical
path where this test was going to be done permanently. But yes, we can
fix it along with the strcpn() = strlen() I added...</font></tt>
<br>
<br><tt><font size=2>   Stefan<br>
</font></tt>