Comment # 8
on bug 9158
from Jeff Morriss
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Jeff, I am not sure I understand your suggestion but my natural idea would
> > > be to display both bitmasks in the subtree of DSAP/SSAP value, the SAP and
> > > the I/G or C/R bit, while not adding any new fields to the top-level tree,
> >
> > Yes, that seems reasonable too. Maybe someone else might have a different
> > opinion on the display in the current patch but to me it does "feel" kind of
> > incomplete or funny. But it may just be me.
>
> Jeff,
>
> I will be happy to update my patch in this way. I would like to ask you for
> a little guidance, though: the DSAP field is split into <7:SAP><1:G/I> bit
> fields, the SSAP field is split into <7:SAP><1:C/R>. If I define a bitmask
> of 0xF7 in the corresponding hf_ entry to isolate the SAP value, any
> proto_tree_add_... function will first shift the SAP value by 1 bit to the
> right and only then use this shifted value when displaying it and when
> translating it to the protocol name. This is obviously wrong. What I need is
> to isolate the SAP value but not shift it during display and conversion to
> protocol name. How can I do this?
Sorry, I've been busy recently.
Oof, the way this stuff is set up doesn't make it easy, does it?
I would guess the "simplest" way to do it would be to store the sap_vals
value_string in shifted format, e.g.:
{ SAP_NULL >>1, "NULL LSAP" },
Since that value_string is used both in val_to_str() calls (with a format
string which presumably should continue to show the un-shifted value) and in
the hf_ fields, I'd guess this would need to be a copy of the current
value_string.
Oh, I guess another way to do it, though, would be to not use VALS() in the hf
but rather use BASE_CUSTOM with a callbackup function which does the necessary
lookup. But that seems like overkill for this case.
You are receiving this mail because:
- You are watching all bug changes.