>Message: 5
>Date: Wed, 16 Apr 2014 08:59:46 +0000
>From: Anders Broman <anders.broman@xxxxxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] adding units
>Message-ID:
> <43C5658BA3FB7B48A6F38EED0B6253F11A96930E@xxxxxxxxxxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="us-ascii"
>
>>I'm tinkering with the 1.10.6 source code
>
>You should be doing it on trunk if you are planning to commit to
>gerrit as this is new functionality.
My group is just now starting to convert to Subversion!, so I maintain
a separate repository with a baseline from the latest release of 1.10.6
for development of the dissector plugin. Well, it's a step up from
Visual SourceSafe.
The reason is that management for this project desired a stable API and
codebase to develop the dissector.
>>and I'm wondering if there's
>>any opinions about the position and placement of units when using the
>>different 'display' enumerations.
>
>
>:
>
>> case BASE_DEC_HEX:
>
>:
>
> } case BASE_HEX_DEC:
>eturn format;
>
>Both these format should probably be treated as BASE_HEX, I can't think
>of a case where something expressed in "units" would need a HEX
>representation.
>
>I would think the prime usage for BASE_HEX, BASE_DEC_HEX and BASE_HEX_DEC
>is when a standard document expresses IEs or Messages in HEX to ease
>comparison with the standard document.
I thought about it and tend to agree with your assessment. I ended up
not populating any unit strings when HEX is in the display type. It made
the implementation a bit simpler too.
I have something that seems to work for the use cases that I have header
fields for, but it's based on 1.10.6 instead of trunk. I checked out
the latest version out of git, and it appears that the API has changed
enough that I'd have to adapt where the changes are made, so is it
worth posting/submitting the proto.c file based on 1.10.6 (to pastebin
perhaps)?
I'd eventually get around to adapting it for the latest wireshark, but
it's kind of out of my scope of work at this time, so I don't know
when exactly that I'd get to it. And trying to add a scale factor may
change things since I need to merge that in and it'll probably end up
in the 'strings' location.
Thanks,
John Dill
<<winmail.dat>>
