ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 39559: /trunk/epan/ /trunk/epan/: pr

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Tue, 25 Oct 2011 16:32:23 -0400
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 BASE_HEX_DEC, treat FT_INTn and FT_UINTn the same.  Change hfinfo_numeric_value_format() the same way.

(so as to prevent "Apply as filter" on a signed BASE_HEX_DEC field whose decimal value is negative from causing an abort).

If that's done we may as well let in BASE_HEX and BASE_OCT too.

This stuff came in rev 24643/bug 1539.  (See the later comments in the bug for at least one developer who wasn't happy about these checks being put in.)

His complaint was about BASE_DEC_HEX and BASE_HEX_DEC; he doesn't want, for example, a 16-bit -1 to show in hex as -0x0001, so it sounds as if BASE_HEX and, presumably, BASE_OCT should show the number as unsigned in either case, so I don't see much point in signed values with BASE_HEX or BASE_OCT - if the number is only displayed in hex or octal, I'd argue it's unsigned.

My thought had been that if you're displaying it in hex at all then it must be unsigned, but apparently that's not really the case.

Agreed on BASE_HEX and BASE_OCT.