Ethereal-dev: Re: [Ethereal-dev] [PATCH] packet-dcerpc.c: clamp to tvb length and display mult
On Fri, 3 Dec 2004, 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.
> Only this will really affect the final outcome anyway.
In answer to the question that Guy posed, I _think_ that we should always
put the padding in the tree, because people can get confused if they are
following along the byte view when clicking on fields in the tree and they
see unaccounted for bytes. It is awfully easy to think the dissector is
wrong, and by the same token, it becomes easier to spot mistakes in the
dissector.
> 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.
Charles, I don't think there is any overt discrimination going on here.
Just a bunch of independent rational actors who look at what has been
contributed and the time they have on hand and their own priorities and
then decide whether or not they can integrate new changes.
> > 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?
While I don't know that I am a leader here, there is certainly an interest
from some people for anything that makes the dissection more accurate.
> Do my contributions to it stand an equal chance of being
> considered in a timely fashion and eventually accepted (once
> revised)?
You know what? One of the easiest ways to deal with this is to give you
commit access to SVN ...
Of course, you have done the right thing. Squeeky wheel and all that :-)
Regards
-----
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
