Wireshark-dev: Re: [Wireshark-dev] FW: DISSECTOR_ASSERT_NOT_REACHED in WLCCP decode...
I'll make that change, but can you point me to an explanation of the
difference between these two? I'm sure it's something to do with unsigned
versus signed, but why does it affect what I'm doing here?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
Kevin.Noll@xxxxxxxxxxxxx
+1-717-796-1936
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Joerg Mayer
Sent: Thursday, May 31, 2007 10:21 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] FW: DISSECTOR_ASSERT_NOT_REACHED in WLCCP
decode...
On Wed, May 30, 2007 at 10:18:13PM +0200, Joerg Mayer wrote:
> On Wed, May 30, 2007 at 01:15:35PM -0700, Stephen Fisher wrote:
> > > So I'm looking at the value strings, and I'm wondering why we
> > > should terminate them with {0, NULL} and what happens if one of
> > > the value pairs needs to be {0, "a real string"} ?
> >
> > You can still use 0, "a real string" as one of the entries. You
> > just need to have 0, NULL as the final entry. If you don't, the
> > code will keep reading past the end and run into random memory space
> > looking for that 0, NULL entry.
>
> And one of those overruns might actually cause the crash you were
> talking about.
I just found another 10 Minutes to actually test the code (with the added
{0, NULL} stuff).
Please replace all FT_UINT_BYTES by FT_BYTES (you've misunderstood the
meaning of _UINT_ in that type. That will get you further (up to some failed
assertion "(guint)hfindex < gpa_hfinfo.len, which means, that you reference
a non-existent hf_ element).
Ciao
Joerg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
