On Tue, Mar 26, 2013 at 2:30 PM, Guy Harris wrote:
>
> On Mar 26, 2013, at 10:31 AM, Evan Huus wrote:
>
>> I'm not 100% convinced we should though - it would be more flexible,
>> but we'd be exposing some of the guts of the dissection backend into
>> 'userspace' as it were. Not a particular stron
On Mar 26, 2013, at 10:31 AM, Evan Huus wrote:
> I'm not 100% convinced we should though - it would be more flexible,
> but we'd be exposing some of the guts of the dissection backend into
> 'userspace' as it were. Not a particular strong objection, but
> something to keep in mind.
I'm not sure
On Tue, Mar 26, 2013 at 1:00 PM, Jakub Zawadzki
wrote:
> Hi,
>
> On Tue, Mar 26, 2013 at 05:39:54PM +0100, David Arnold wrote:
>> Is there any enthusiasm for a BASE_CUSTOM64?
>
> I'd rather want some generic BASE_CUSTOM which pass to custom functiom
> fvalue_t (and maybe hf_index).
It looks like
On 25/03/2013, at 10:23 PM, Jeff Morriss wrote:
> On 03/17/13 11:58, David Arnold wrote:
<...>
>> My question then becomes one of consistency: should I do this for all my
>> BASE_CUSTOM cases? Or is there some advantage in using BASE_CUSTOM that
>> I've missed (beyond saving a couple of line
Hi,
On Tue, Mar 26, 2013 at 05:39:54PM +0100, David Arnold wrote:
> Is there any enthusiasm for a BASE_CUSTOM64?
I'd rather want some generic BASE_CUSTOM which pass to custom functiom fvalue_t
(and maybe hf_index).
Jakub.
_
On 03/17/13 11:58, David Arnold wrote:
On 14/03/2013, at 10:36 PM, Guy Harris wrote:
You could use proto_tree_add_uint64_format_value().
I ended up writing a
static void
foo_tree_add_timestamp(
proto_tree *tree,
const int hf,
tvbuff_t *tvb,
gint
On 14/03/2013, at 10:36 PM, Guy Harris wrote:
> You could use proto_tree_add_uint64_format_value().
I ended up writing a
static void
foo_tree_add_timestamp(
proto_tree *tree,
const int hf,
tvbuff_t *tvb,
gint offset);
which extracts the value using tvb_g
On Mar 14, 2013, at 1:44 PM, David Arnold wrote:
> It's implicit, and midnight today (the protocol is NASDAQ OUCH-4.x)
You could use proto_tree_add_uint64_format_value().
___
Sent via:Wireshark-dev mailing list
Archive
On 14/03/2013, at 9:32 PM, Guy Harris wrote:
> On Mar 14, 2013, at 1:22 PM, David Arnold wrote:
>
>> I'm working on a dissector for a protocol that encodes a timestamp as a
>> 64-bit number of nanoseconds since midnight.
>
> Is that "midnight on a particular date", where the date appears in th
On Mar 14, 2013, at 1:22 PM, David Arnold wrote:
> I'm working on a dissector for a protocol that encodes a timestamp as a
> 64-bit number of nanoseconds since midnight.
Is that "midnight on a particular date", where the date appears in the packet
along with the time-of-day, or is it "midnigh
Hi all,
I'm working on a dissector for a protocol that encodes a timestamp as a 64-bit
number of nanoseconds since midnight. I'd like to write a BASE_CUSTOM
formatting function for this field, but it looks like the value passed to
formatting functions for BASE_CUSTOM is limited to 32 bits (fr
11 matches
Mail list logo
