Comment # 8
on bug 9612
from Evan Huus
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Thanks for the feedback, I am applying your suggestions. As the FT_NONE ->
> > > FT_.. replacement is quite tricky (many AMQP types can be decoded as uint8
> > > or uint16 or so, depending on type descriptor; hence I have to dynamically
> > > change/set proper ft_amqp_1_0_* variable after decoding the descriptor), it
> > > will take very few weeks to propose new version of patch.
> >
> > Dynamically setting ft_ values really shouldn't be necessary (and is
> > generally avoided as bugs in it can be really hard to track down).
> >
> > I was thinking of fields like hf_amqp_1_0_creationTime which (if I am
> > reading the APQM spec correctly) are required to be timestamps and therefore
> > can be statically set to type FT_TIME. In fact, skimming the spec there are
> > very few fields whose type is actually listed as "*" (which presumably means
> > it can be many things depending on the type descriptor).
> >
> > (spec I found, hopefully the right one:
> > http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf)
>
> Yes, the spec is proper one. By different types, I meant also e.g.:
>
> <field name="max-frame-size" type="uint" default="4294967295"/>
>
> where uint type is:
>
> <type name="uint" class="primitive">
> <encoding code="0x70" category="fixed" width="4"
> label="32-bit unsigned integer in network byte order"/>
> <encoding name="smalluint" code="0x52" category="fixed" width="1"
> label="unsigned integer value in the range 0 to 255 inclusive"/>
> <encoding name="uint0" code="0x43" category="fixed" width="0" label="the
> uint value 0"/>
> </type>
>
> I.e. max-frame-size with value 0 can be encoded as either hexstream:
> 700000 (4bytes uint with zero value)
> 5200 (smalluint with zero value)
> 43 (uint0 with zero value width)
>
> Having just one hf_amqp_1_0_* variable for max-frame-size means ambiguity in
> specifying FT_ to either FT_UINT32, FT_UINT8 or FT_NONE.
>
> I wrote my previous comment confusingly. My aim is to:
> - have 3 hf_* variables for max-frame-size, depending on value width, one as
> default (e.g. uint0)
> - when dissecting max-frame-size (that I know by proper hf_* variable), if
> the uint is smalluint, use proper hf_* variable rather than the default
>
> So I dont plan to change "static hf_register_info hf[]" or values of hf_*
> variables, I just will use the proper hf_* variable, based on just-decoded
> particular type.
Ah, OK that's fine. You probably don't need a third value for uint0 though, you
can just proto_tree_add_uint and specific the uint8 value with the explicit
value 0 and no length.
Also note that there is a small section in README.dissector (1.5.1 I believe)
dealing with the limits of multiple-format-registration. I don't think they
will cause you problems, but worth keeping in mind.
You are receiving this mail because:
- You are watching all bug changes.