You may have noticed "proto_tree_add_item_ret_display_string()" and perhaps
found that it doesn't do what you want; it produces the display string for
a default display representation and doesn't use your custom function.
(Perhaps it should?)
On Tue, Sep 12, 2023, 10:05 AM John Thacker wrote:
> In general you don't want to do that, if your goal is to create an expert
> info. The string would not exist and thus the Expert Info would not show in
> the "Analyze -> Expert Information" dialog, or in other situations where
> the tree was not visible and the item was faked; you might have to
> specifically filter for the item. (See
> https://gitlab.com/wireshark/wireshark/-/issues/18955 for a similar
> situation. Also somewhat relatedly
> https://gitlab.com/wireshark/wireshark/-/issues/19216 ) For optimization
> purposes, strings and display labels are not filled in unless necessary.
>
> What you could do is allocate your own string buffer, and pass it and the
> uint64_t to your Receive_Frequency function. You can simplify that by
> replacing your proto_tree_add_item() call with:
>
> uint64_t value;
> char[ITEM_LABEL_LENGTH] label;
> ti = proto_tree_add_item_ret_uint64(tree, hf_, tvb, start, length,
> encoding, &value);
> Receive_Frequency(label, value);
> if () {
> expert_add_info(pinfo, ti, &ei_);
> }
>
> However, since it's processor intensive and error prone to convert to a
> string only to parse the string back to floating point, you'd probably be
> better off retrieving the uint64_t value and passing it to a function that
> converts it directly to the floating point you need, separate from your
> custom display function.
>
> Cheers,
> John Thacker
>
>
> On Thu, Sep 7, 2023 at 12:15 PM John Dill
> wrote:
>
>> I have a question whether I can get the dissected string of the
>> BASE_CUSTOM header field so that I can do analysis on it and convert it to
>> floating point to do range analysis so I can issue an expert info if the
>> value is valid but out of range.
>>
>>
>> {
>> &hf_Receive_Frequency,
>> {
>> "Receive Frequency",
>> "Receive_Frequency",
>> FT_UINT48,
>> BASE_CUSTOM,
>> CF_FUNC(Receive_Frequency),
>> 0x0,
>> NULL,
>> HFILL
>> }
>> },
>>
>> ...
>>
>> ti = proto_tree_add_item(word_tree,
>> hf_XTS_5000_APX_8000_Receive_Frequency, tvb, offset, 6, ENC_BIG_ENDIAN);
>>
>> ...
>>
>> static void Receive_Frequency(gchar *result, guint64 value)
>> {
>> guint16 w_Base_Frequency;
>> guint16 w_1_MHz_BCD;
>> guint16 w_100_KHz_BCD;
>> guint16 w_10_KHz_BCD;
>> guint16 w_Rx_KHz_Frequency_Field;
>>
>> guint32 MHz_Frequency;
>> guint32 KHz_Frequency;
>>
>> ... processing ...
>>
>> switch (lut_Base_Frequency[w_Base_Frequency])
>> {
>> case -1:
>> g_snprintf(result, ITEM_LABEL_LENGTH, "Illegal");
>> break;
>>
>> case 0:
>> g_snprintf(result, ITEM_LABEL_LENGTH, "Invalid");
>> break;
>>
>> default:
>> /* Frequency is typically displayed in MHz with 4 significant
>> digits */
>> g_snprintf(result, ITEM_LABEL_LENGTH, "%" G_GUINT32_FORMAT ".%"
>> G_GUINT32_FORMAT " MHz", MHz_Frequency, KHz_Frequency / 100);
>> break;
>> }
>> }
>>
>> Is there a way for me to peel the dissected result string from "ti" after
>> the proto_tree_add_item call so that I can do validation and range checking
>> for expert info?
>>
>> Can I try to hijack proto_item_fill_display_label to somehow push "tmp"
>> out of the interface into a proto_tree_add_*_ret_processed_string?
>>
>> \code
>> if (FIELD_DISPLAY(hfinfo->display) == BASE_CUSTOM) {
>> gchar tmp[ITEM_LABEL_LENGTH];
>> custom_fmt_func_t fmtfunc = (custom_fmt_func_t)hfinfo->strings;
>>
>> DISSECTOR_ASSERT(fmtfunc);
>> fmtfunc(tmp, number);
>>
>> label_len = protoo_strlcpy(display_label_str, tmp, label_str_size);
>> \endcode
>>
>> This 'tmp' from fmtfunc is the string I want to grab for post-analysis,
>> but it seems non-obvious how to get at it.
>>
>> I might be completely overlooking an easy way to do this.
>>
>> Any suggestions? I already maintain a fork, so having a custom mod to
>> pull this out is on the table for me.
>>
>> Thanks,
>> John D.
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
