Thank you both for these comprehensive answers :)
On Mon, Oct 24, 2011 at 7:27 PM, Guy Harris g...@alum.mit.edu wrote:
On Oct 24, 2011, at 8:49 AM, Teto wrote:
tvb_get_letoh24 / tvb_get_letohl look more straightforward but I don't
understand how they transform the number.
letoh stands for
When i try to compile Wireshark rev. 37286 ( but also the last ) on my Mac OSX
Lion 10.7.2
Darwin 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011;
root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
llvm-gcc-4.2
I have this problem:
libtool: compile: gcc -DHAVE_CONFIG_H -I.
Hi,
1st question:
It took me some time but thanks to README.developer I think I
understand how display filtering works now. I was wondering if it was
possible to update an item's header field id after its creation. For
example:
proto_item* pi = proto_tree_add_text(subtree,tvb,offset,4,Type:
On Oct 25, 2011, at 3:48 AM, s...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39559
User: stig
Date: 2011/10/25 03:48 AM
Log:
Allow signed integers displayed as DEC_HEX.
So should a 32-bit -1 be displayed as 0x or -0x1?
On Oct 25, 2011, at 8:26 AM, Teto wrote:
1st question:
It took me some time but thanks to README.developer I think I
understand how display filtering works now. I was wondering if it was
possible to update an item's header field id after its creation.
No.
For example:
proto_item* pi =
On Tue, Oct 25, 2011 at 6:21 PM, Guy Harris g...@alum.mit.edu wrote:
Log:
Allow signed integers displayed as DEC_HEX.
So should a 32-bit -1 be displayed as 0x or -0x1?
I was thinking more like -1 (0x), which would be the case for DEC_HEX.
--
Stig Bjørlykke
On Oct 25, 2011, at 9:40 AM, Stig Bjørlykke wrote:
On Tue, Oct 25, 2011 at 6:21 PM, Guy Harris g...@alum.mit.edu wrote:
Log:
Allow signed integers displayed as DEC_HEX.
So should a 32-bit -1 be displayed as 0x or -0x1?
I was thinking more like -1 (0x), which would be the
On Tue, Oct 25, 2011 at 6:48 PM, Guy Harris g...@alum.mit.edu wrote:
On Oct 25, 2011, at 9:40 AM, Stig Bjørlykke wrote:
I was thinking more like -1 (0x), which would be the case for
DEC_HEX.
That's BASE_DEC_HEX; if that's what they wanted, that's what they should have
specified.
On Oct 25, 2011, at 10:49 AM, Stig Bjørlykke wrote:
But now I don't understand the question...
Sorry, I misread the checkin comment
Allow signed integers displayed as DEC_HEX.
as
Allow signed integers displayed as BASE_HEX.
It might have been a bit harder to misread if it
On Tue, Oct 25, 2011 at 7:56 PM, Guy Harris g...@alum.mit.edu wrote:
We should probably allow BASE_HEX_DEC as well.
I was thinking about it. It may make as much sense as allowing BASE_DEC_HEX.
--
Stig Bjørlykke
___
Sent
Guy Harris wrote:
On Oct 25, 2011, at 10:49 AM, Stig Bjørlykke wrote:
But now I don't understand the question...
Sorry, I misread the checkin comment
Allow signed integers displayed as DEC_HEX.
as
Allow signed integers displayed as BASE_HEX.
It might have been a bit
On Oct 25, 2011, at 11:43 AM, Jeff Morriss wrote:
also require modifying hfinfo_numeric_format() to be able to generate
representations of negative hexadecimal numbers
I'd say the representation should just be an unsigned representation. I.e.,
for BASE_HEX and BASE_HEX_DEC, treat FT_INTn
On Tue, Oct 25, 2011 at 8:43 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
If that's done we may as well let in BASE_HEX and BASE_OCT too.
Do you think? This would abandon the sign on negative values, and may
not be what the user expects?
--
Stig Bjørlykke
Guy Harris wrote:
On Oct 25, 2011, at 11:43 AM, Jeff Morriss wrote:
also require modifying hfinfo_numeric_format() to be able to generate
representations of negative hexadecimal numbers
I'd say the representation should just be an unsigned representation. I.e.,
for BASE_HEX and
14 matches
Mail list logo
