Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 48633: /trunk/epan/ /trunk/epan/: va
I've tried to clean up most of them (along with a few other of the decode_* functions) to be replaced with proto_tree_add_item (with masks in the hf items as needed), but I think the few remaining were a bit hard to decipher without a sample capture (which I didn't have). If I could get rid of all of them, I would have to "encourage" the use of proto_tree_add_item.
-----Original Message-----
From: Evan Huus <eapache@xxxxxxxxx>
To: Wireshark Developer List <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thu, Mar 28, 2013 6:15 pm
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 48633: /trunk/epan/ /trunk/epan/: value_string.c
On Thu, Mar 28, 2013 at 6:02 PM, <eapache@xxxxxxxxxxxxx> wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=48633
>
> User: eapache
> Date: 2013/03/28 03:02 PM
>
> Log:
> Greatly clean up value_string.c
> - use consistent indentation and coding style
> - add modelines
> - replace some g_assert calls with DISSECTOR_ASSERT where it makes sense
> - group related functions together and simplify many comments by referring
to
> the 'normal' value_string as the canonical version
>
> Directory: /trunk/epan/
> Changes Path Action
> +366 -328 value_string.c Modified
Tangential to this, does anybody know what the deal is with
decode_enumerated_bitfield() and decode_enumerated_bitfield_shifted()?
The first is called in exactly one place, the second not at all. They
return static buffers (which is odd, though not necessarily wrong,
perhaps they should be using packet-scope memory?), and while they
make use of value strings they don't seem immediately value-string
related.
The only one that is called is fairly short so I'm tempted to manually
inline that and drop both functions. At the very least they should
probably be moved to to_str.c (or somewhere else).
Thoughts?
Evan
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
