Gerhard Gappmeier wrote:
> it loads the file imediately on my computer without any delay.
> I tried the fuzzy file also with tshark.
> I called "tshark -r sample.cap", is this right?
> Because it didn't crash for me. I tried it several times.
>
> Any ideas why it behaves different for you?
> I'm currently working on revision 21246.
> Compiled with VC6 on windows.
>
Gerald already gave you some notes. BTW: accessing "unknown" memory can
result in virtually *every* possible response ...
>> Some points that I've seen immediately:
>> - you *must* end *every* value_string you use by a an ending sequence
>> { 0, NULL }, otherwise unexpected values coming from the network will
>> result in an access
>>
> Ok, I'll fix that.
>
That's the main point that *needs* to be fixed and I guess it's the
cause of the regression test problems. Unless there are other problems
as well ;-)
>> violation, as the corresponding access functions will run into the
>> wrong memory areas
>> - e.g. opcua.c / g_szMessageTypes unnecessarily re-implements a
>> value_string - this bloats code size and complexity
>>
>>
> I don't know how to do this with value_string.
> I'm parsing textual protocol message signatures and not numbers:
> e,g, "UATH" -> "Hello Message"
> "UAMA" -> "Abort Message"
> ...
> static char* g_szMessageTypes[] =
> {
> "Hello message",
> "Acknowledge message",
> "Disconnect message",
> "Data message, last chunk in message.",
> "Data message, further chunks must follow.",
> "Abort message",
> "Error message",
> "Invalid message",
> "Unknown message"
> };
> How does this small string table bloat the code size?
> It wouldn't be smaller with value_string.
> And the parsing code always defaults to "Unkown message", so there is no
> way for an out of bounds szenerio
> like with the value_string arrays and so I don't need NULL at the end here.
>
Sorry for the noise, I didn't saw the pfctParse, so you'll actually need
the if/switch construct anyway, regardless of the strings - just forget
this one ...
Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
