Ethereal-dev: Re: [Ethereal-dev] [PATCH] packet-dcerpc.c: clamp to tvb length and display mult
Charles Levert wrote:
* On Friday 2004-12-03 at 02:39:46 -0800, Guy Harris wrote:
There are other places in the DCE RPC dissector - and other dissectors -
where padding isn't put into the protocol tree. Should it always be put
into the protocol tree?
I am not in a position to make decisions for this project, but you are.
I would be pointless for me to even start answering those questions when
you could just explicitly state what your (and other project leaders')
vision and priorities are on such a matter or the similar ones below.
You're assuming, perhaps incorrectly, that the people in question *have*
a view. There are places in dissectors where padding is put into the
protocol tree, and places where it's not; I'm asking the question to see
what people in general think. The question came up because you added it
only in one place - I didn't see why that particular place was any
different from the other places in the DCE RPC dissector where padding
was added, so if it belonged there, it presumably belonged in other places.
I am willing to explore this and I already anticipate challenges in trying
to provide a generic facility, but before I commit any time in doing so,
I have to know the following:
Is there any interest in the subject from the project leaders?
"The subject" meaning moving the multi-line display stuff into the
generic string code? I can't speak for other project leaders, but
that's where I think it belongs, so I'd say I'm interested in it.
I don't think it's that complicated to provide. I would be tempted not
to make it apply to all strings, as, if a string *doesn't* contain any
newlines, I don't think there should be a subtree for it, so the code
would have to scan all strings, and I'd prefer not to spend CPU time on
scanning strings that are for fields that aren't likely to contain
newlines - it sounds as if the string in question is a message to be
displayed in a popup on the user's machine - although if the extra CPU
time doesn't slow Ethereal down significantly, perhaps it should apply
to all strings. Perhaps it should be done for all strings, and then
changed to have the field specify whether to do it or not if a lot of
CPU time is used.
Do my contributions to it stand an equal chance of being
considered in a timely fashion and eventually accepted (once
revised)?
How quickly changes get considered depend on the availability of time to
consider them, the complexity of the changes, the depth of the issues
they raise - and whether the issues happen to get noticed, so for better
or worse, it can be somewhat random. At this point, I'll look at your
changes, time permitting, and accept them if I think they're reasonable.
