Wireshark-bugs: [Wireshark-bugs] [Bug 8431] New Dissector Patch - USB PTP / MTP
Date: Thu, 18 Apr 2013 17:05:08 +0000

Comment # 40 on bug 8431 from
(In reply to comment #39)
> (In reply to comment #38)
> > Regarding masked value strings, I'm still not clear on the intention here.
> > This is likely due to the fact that I don't have any real understanding of
> > the protocol, but the two-pass check in table_value_from_mask is very
> > confusing.
> > 
> > If this is something that might be generically useful then the entire thing
> > (including table_value_from_mask and related) should be split off and made
> > generic (ie not hard-coding USB_PTP_FLAVOR_MTP). However, given the odd
> > nature of I am no longer sure - again I don't really understand what it's
> > supposed to be doing.
> > 
> 
> I already made it generic in the above patch.

I was referring not just to the structure but to the accessor functions
(table_value_from_mask etc.) as well. That function references
USB_PTP_FLAVOR_MTP directly which is why I wasn't sure if it was possible to
make it generic or not.

> The idea is that each item
> in the table may or may not be valid depending on the state of the
> conversation.   This makes the tables a dynamic lookup instead of a static
> one.   Example : connection handles MTP or not, so we do or don't use
> entries that have the MTP flag.   More than one flag can be set at a time. 

This does sound like something that could be made generic, although I'm still
not clear on the two-pass logic. From this explanation it sounds like there
should still only be one pass, but that entries not matching the mask should be
ignored rather than checked?

Is it possible for the same value to have two different entries with disjoint
masks, so that only one of them is selected at a given time? If not it may be
simpler to do this as a regular value string, use the existing accessor
functions, and then check the mask afterwards to determine if you're "allowed"
to use the returned value or not.

> > - On my machine the compiler spits out an enourmous number of errors, I
> > think you're missing an include or something?
> 
> I can't reproduce this, I'm able to compile in Linux and Windows, 32bit and
> 64bit.   You'll have to give me more output here.

My fault, I forgot to apply the separate patch for masked value strings when
compiling, so those weren't defined. Apologies.

---

One additional oddity caught by cppcheck:
epan/dissectors/packet-usb-ptp.c:229: warning: Assignment of function parameter
has no effect outside the function.


You are receiving this mail because:
  • You are watching all bug changes.