After committing the main change for this (minus the ISUP part), I did play around some more with this check. This included:
- checking for non-inclusive overlap (i.e. some overlapping, some not)
- check to see if collectively all of the earlier entries hide a later one
I didn't find any definite bugs, but was surprised to see the use of -ve values being used (value_min and value_max are guint32) with an FT_INT16 field.
e.g.
{ &hf_mq_tsh_ccsid , {"CCSID.....", "mq.tsh.ccsid", FT_INT16, BASE_DEC | BASE_RANGE_STRING, RVALS(GET_VALRV(ccsid)), 0x0, "TSH CCSID", HFILL }},
So the field is being dissected as a 16-bit signed value.
The value_string array itself is defined (using nested macros) as:
DEF_VALRB(ccsid)
/* -4*/ DEF_VALR1(MQCCSI_AS_PUBLISHED),
/* -3*/ DEF_VALR1(MQCCSI_APPL),
/* -2*/ DEF_VALR1(MQCCSI_INHERIT),
/* -1*/ DEF_VALR1(MQCCSI_EMBEDDED),
/* 0*/ DEF_VALR3(MQCCSI_UNDEFINED, MQCCSI_UNDEFINED, "UNDEFINED/DEFAULT/Q_MGR"),
/* >=1*/ DEF_VALR3(MQCCSI_1, MQCCSI_65535, ">=1"),
DEF_VALRE;
If you cast (gint16)(-4) to a guint32 and back again, it at least gave me the same answer, so I believe it'll work for single values. What wouldn't work is if you had e.g.
( -2, 2, "Something" }
As the min field will be cast to something much bigger than 2, so the (min <= val <= max) test could never pass. However, this isn't happening, or my existing check for max being <= min would have flagged it.
Martin
