Ethereal-dev: Re: [Ethereal-dev] [PATCH] packet-dcerpc.c: clamp to tvb length and display mult
* 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.
Only this will really affect the final outcome anyway.
There are bound to be opportunities for consolidation in any project that
is developed in an incremental fashion and in reaction to newer outside
developments (e.g., new protocols). There are plenty of precedents in
Ethereal where such opportunities have not yet been taken and ad hoc code
has been accepted instead; that's quite all right and understandable,
but I can't help but wonder if my proposals are being evaluated on an
equal footing.
> Should that be done for *all* strings, or just for *some* strings? And
> should it be done only if the string contains at least one newline?
>
> And should this be done in lower-level code, i.e. in the code that puts
> a string value into the protocol tree, so that it's done for all
> dissectors that put FT_STRING, FT_STRINGZ, or FT_UINT_STRING fields into
> the protocol tree, or for selected strings of that type, regardless of
> whether it's in DCE RPC or not?
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?
Do my contributions to it stand an equal chance of being
considered in a timely fashion and eventually accepted (once
revised)?
