Re: [Ethereal-dev] [PATCH] packet-dcerpc.c: clamp to tvb length and display multiple lines

[Guy Harris <gharris@xxxxxxxxx>]

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.