On Thu, Dec 27, 2001 at 01:26:59PM +0200, Paul Ionescu wrote:
> As far as I remember, there is only one value_string array that has no
> {0 ,NULL} termination
> , the dlsw_pri_vals[] , and this is because it has all values possible
> (from 0 to 7), so there will always be a match.
> This array is only checked by
> match_strval((tvb_get_guint8(tvb,22)&7),dlsw_pri_vals)) which should be
> always in the proper range.
> If you have comments to this observation, please tell me.
Well, I have a comment...
...that's not the only reason why a "value_string" array needs a
terminator.
In addition to being used to look up the string for a given numerical
value, it's *also* used in the "Add Expression" dialog box, when
constructing a filter. If a filterable field has a "value_string" array
associated with it, and the user selects it in that dialog box and
selects a test other than "is present" (e.g., selects "=="), the dialog
box displays a list of the strings for that that field, so the user can
select a value by name rather than having to know that, for example, the
opcode for a reverse ARP request is 0x3 (which I happened to know only
because I had Ethereal running right now, selected "Opcode" from the
list of ARP/RARP fields, selected "==" as an operator, selected "reverse
request", and saw "0x3" pop up).
So, *if* no filterable field uses a "value_string" array, and *if* it's
impossible for a value not in that array to be used with that
"value_string" array, *than* you can get away with having no
termination.
On the other hand, the termination will cost at most 16 bytes, as far as
I know, on any of the platforms on which Ethereal runs (8 bytes for a
pointer, and either 4 bytes + 4 bytes of padding or 8 bytes for a
numerical value, on a 64-bit platform if Ethereal is built as a 64-bit
application), so I think the cost of giving all "value_string" arrays a
terminator doesn't seem to me to be high enough so that you should avoid
them in those cases where you don't need them.
