Re: [Wireshark-dev] address to string optimization

[mmann78]

Made a "first draft" at https://code.wireshark.org/review/7019/
 
 
-Original Message-
From: Guy Harris 
To: Developer support list for Wireshark 
Sent: Fri, Jan 16, 2015 10:55 pm
Subject: Re: [Wireshark-dev] address to string optimization



On Jan 16, 2015, at 11:34 AM, mman...@netscape.net wrote:

> I still like the idea of the address types being "centrally registered" (in 
> epan directory) and not put into the dissector code, mostly because many of 
> the address types are used in multiple dissector/protocols.

Perhaps libwireshark should export a core set of AT_ values and, if it turns 
out to be useful, allow dissectors to register their own private address types 
as well ("private" meaning "nobody else cares about them", so that there's no 
advantage to putting code for them in the libwireshark core).

I'd still check out switches and ifs that check for AT_ values and try to make 
them call functions instead.

> You may also introduce epan dependencies (like from proto.c) with the 
> dissectors, and I think that should be avoided (yes I know some exist, but 
> I've been working to slowly remove them).

Presumably meaning "core libwireshark code in the epan directory being 
dependent on dissector code in epan/dissectors".

> I just really like the idea that a series of properly structured function 
> callbacks could eliminate a lot of the sprintf processing of the "address to 
> string" and drastically improve performance (since almost all packets do some 
> time of address to string processing).  Also included could be standards in 
> displaying "address string" + "address name resolution" formatting.  
> Personally I like the %s (%s), for address string then resolution,

...although that's the opposite of what we do for enumerated-type numeric 
values, where we give the name, followed by the numeric value in parentheses.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

 
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] lua_bitop.c: MSVC2013 Code Analysis Warning

[Hadriel Kaplan]

I'll take a look.
-hadriel


On Feb 7, 2015, at 4:54 PM, Bill Meier  wrote:

> Hadriel:
> 
> MSVC2013 Code Analysis is giving the following warning:
> 
> 
> ...\ws-git\epan\wslua\lua_bitop.c(116) : warning C6297: Arithmetic overflow:  
> 32-bit value is shifted, then cast to 64-bit value.  Results might not be an 
> expected value.
> 
> After quick look at the code, my reaction:
>  Uh Oh... Twisty maze of passages
> 
> So I'm going to punt.
> 
> Can you take a look (or redirect upstream) or whatever ?
> 
> Thanks
> 
> Bill

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] lua_bitop.c: MSVC2013 Code Analysis Warning

[Bill Meier]

Hadriel:

MSVC2013 Code Analysis is giving the following warning:


...\ws-git\epan\wslua\lua_bitop.c(116) : warning C6297: Arithmetic 
overflow:  32-bit value is shifted, then cast to 64-bit value.  Results 
might not be an expected value.


After quick look at the code, my reaction:
  Uh Oh... Twisty maze of passages

So I'm going to punt.

Can you take a look (or redirect upstream) or whatever ?

Thanks

Bill
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe