Ethereal-dev: Re: [Ethereal-dev] [PATCH] packet-dcerpc.c: clamp to tvb length and display mult
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guy I have to agree.
I would like to see any changes like this limited to the specific
dissectors that need it, as
opposed to changing it, and possibly breaking parsers for the
current dcerpc dissectors.
On Fri, 03 Dec 2004 10:12:09 -0800 Guy Harris <gharris@xxxxxxxxx>
wrote:
>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.
>
>_______________________________________________
>Ethereal-dev mailing list
>Ethereal-dev@xxxxxxxxxxxx
>http://www.ethereal.com/mailman/listinfo/ethereal-dev
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4
wkYEARECAAYFAkGzJnMACgkQFh/Ot+gyoF5t3ACfUv5YBuKY6JAFuJbLNqB2IUA130kA
mwYE9U1/pZV4Q3g1+8cSPR+8MOYP
=0FC5
-----END PGP SIGNATURE-----
