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

Wireshark-dev: [Wireshark-dev] What ftypes are "compatible" enough for duplicate fields?

From: Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx>
Date: Fri, 21 Feb 2014 13:19:36 -0500
Howdy,
Along the lines of bug 2402, I'm adding verification code to prevent Lua script duplicate field registration (bug 9709). The idea is to allow duplicate fields if their ftypes are "similar" enough; otherwise reject it.

The question, though, is what ftypes are similar enough?

There's a patch in bug 2402 to check for mismatches, which makes the following equivalence choices:

	case FT_INT8:
	case FT_INT16:
	case FT_INT24:
	case FT_INT32:
		return FT_INT32;

	case FT_UINT8:
	case FT_UINT16:
	case FT_UINT24:
	case FT_UINT32:
	case FT_IPXNET:
	case FT_FRAMENUM:
		return FT_UINT32;

	case FT_UINT64:
	case FT_EUI64:
		return FT_UINT64;

	case FT_STRING:
	case FT_STRINGZ:
	case FT_UINT_STRING:
		return FT_STRING;

	case FT_FLOAT:
	case FT_DOUBLE:
		return FT_DOUBLE;

	case FT_BYTES:
	case FT_UINT_BYTES:
	case FT_ETHER:
	case FT_OID:
		return FT_BYTES;

	case FT_ABSOLUTE_TIME:
	case FT_RELATIVE_TIME:
		return FT_ABSOLUTE_TIME;

	default:
		return type;

Are those the right equivalence groups?  I was thinking all unsigned and signed numbers should be equal, maybe even including floats and doubles. Ultimately the only impact this all really has, as far as I can tell so far, is on display filters (and verification of the filter string?).

-hadriel