Ethereal-dev: Re: [Ethereal-dev] (no subject)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "packet steve" <packetsteve@xxxxxxxxxxx>
Date: Mon, 06 Oct 2003 08:32:57 -0400
I later noticed that Michael Lum's ranap patch slightly overlaps mine. Next time I'll diff versus current cvs.

You're probably right about ranap.ie.number_of_ProtocolExtensionFields. If there are no contrary opinions, we can use ranap.number_of_ProtocolExtensionFields (easier to type).

Crashing in the registration code would keep the code cleaner.


From: Guy Harris <guy@xxxxxxxxxxxx>
To: packet steve <packetsteve@xxxxxxxxxxx>
CC: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] (no subject)
Date: Mon, 6 Oct 2003 01:38:53 -0700

On Sun, Oct 05, 2003 at 10:12:27AM -0400, packet steve wrote:
> When writing proto_register_xx, its easy to create unintended duplicates.
>
> I've attached patches against 0.9.15 for
> packet-dcerpc-rpriv.c
> packet-dcerpc-spoolss.c
> packet-isup.c
> packet-nlsp.c
> packet-ranap.c
> packet-sua.c
> to remove the exact duplicates I noticed. Please consider these patches.

Checked in (although some of the RANAP patches don't apply to the
current version, and it looked offhand as if the "numer of protocol
extensions field" one should have deleted
"ranap.ie.number_of_ProtocolExtensionFields" rather than
"ranap.number_of_ProtocolExtensionFields" - if that's not the case, let
me know).

Arguably, the registration code should crash if the hf_ variable being
initialized isn't -1, although in the dissectors where they aren't
variables but are members of an array, they might not be initialized to
-1, so that'd need to be fixed, or we'd need to allow 0 or -1; the
latter would probably be sufficient to catch most if not all of these bugs.

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup