Andy.Ling@xxxxxxxxxxx wrote:
Fine, but then why should it cope with an offset of 0. You shouldn't be
trying to add a protocol tree item when the offset is 0, there's
no data there either.
Eh? An offset of 0 just means "beginning of the packet".
If you mean "length of 0", then a length of 0 is used in two places:
1) generated items, where neither the offset nor the length are meaningful;
2) the top-level item for a protocol if the amount of data available
for the protocol is 0 - that allows the top-level item to be added, with
the exception thrown when you create the sub-item.
We could discuss the semantics of this all day, but it's not fixing
the problem. I have perfectly good CORBA packets that are showing
up as errors. I have spent a fair bit of time finding out why and
now I'd like some help to find the best way to fix it.
I agree with you that proto_tree_add_item should not be called if
there is nothing to add and I said as much in one of my earlier
posts, but the current code is based on the principle that this
can be done.
It's not as if somebody necessarily explicitly said "I'll write this on
the assumption that there are always parameters to a call" - it might
have been written without bearing in mind that there aren't (i.e., it's
not as if it's a Fundamental Design Decision).
I'd suggest moving the start_dissecting() calls into the routines that
process individual procedure requests and replies, and avoid generating
those calls if there are no items expected.
See, for example, genOperationRequest() in wireshark_gen.py; it could,
for example, start out by setting a flag to false and, before the
self.getCDR3() call, if the flag is false, put out the
start_dissecting() call and set the flag to true, so that the
start_dissecting() call is put out before the first parameter.
