Wireshark-bugs: [Wireshark-bugs] [Bug 1699] Bad decoding of Camel PromptAndCollectUserInfo
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1699
------- Comment #3 from florent.drouin@xxxxxxxxxx 2007-07-23 15:25 GMT -------
I am not sure the problem can be solved by changing the definition of the
hf_field
For example, hf_camel_promptAndCollectUserInformation is used for the operation
PromptAndCollectUserInformation Invoke and Result (even if the result is
decoded with ReceivedInformationArg ).
For the invoke, FT_NONE is appropriate (decoding of a SEQUENCE), but for the
Result, an integer value should be used (because of the decoding of a CHOICE).
As it is currently not possible to use FT_NONE for the Invoke and FT_UINT for
the result, because the hf_field is related to an Operation
(PromptAndCollect..) and not to an Operation Invoke or Operation Result, I
don't think this problem can be solved with a better autogeneration of the
hf_field.
I think, we should allow the use of FT_NONE in dissect_ber_choice, and create
the tree related to the message (something like in dissect_ber_sequence),
instead of rejecting this value.
Like this, there is no need to change the generation process from ASN1 file.
Do you agree with this analyze ?
(Maybe FT_NONE should be replaced by FT_MESSAGE to avoid unexpected impact on
existing code )
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
