Comment # 7
on bug 9612
from Pavel Moravec
(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.
You are receiving this mail because:
- You are watching all bug changes.
