Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] New proto_add_bits function (Was: rev 21556: /trunk/epan//tr...)

From: Joerg Mayer <jmayer@xxxxxxxxx>
Date: Thu, 26 Apr 2007 10:20:36 +0200
On Wed, Apr 25, 2007 at 08:06:26PM +0200, Anders Broman wrote:
> I'm looking inot spliting it into:
> 
> /*This function will call proto_tree_add_bits_ret_val() without the return
> value. */
> extern proto_item *
> proto_tree_add_bits(proto_tree *tree, int hf_index, tvbuff_t *tvb, gint
> bit_offset, gint no_of_bits, gboolean little_endian);
> 
> /* Calls tvb_get bits */
> extern proto_item *
> proto_tree_add_bits_ret_val(proto_tree *tree, int hf_index, tvbuff_t *tvb,
> gint bit_offset, gint no_of_bits, guint32 *return_value, gboolean
> little_endian);
> 
> 
> guint32
> tvb_get_bits(tvbuff_t *tvb, gint bit_offset, gint no_of_bits, gboolean
> little_endian)
> 

That sound much better. That way, we may add functions including the
retval for the other proto_tree_add stuff as well.

> (Should it handle 64bits?)

I think so.

> If that's a more acceptable format. It would be good if we could agree on a
> format and get down to the nitty gritti of fixing up the functions.

Now, the only stuff left to talk about are which other secanrios might
be possible as well, regarding the bits stuff:

Should endianess be taken into account? Should canonical vs
non-canonical be taken into account?

 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.