Hi John, Thanks for chipping in. There’s one blocking issue with these ideas though, they can’t be back ported to stable release(s). Still these could be interesting additions to the dissection engine API, so you could either start a separate thread on this list with a well worked out proposal, or work through en enhancement bug.
Thanks, Jaap > On 7 Jul 2020, at 01:30, John Thacker <johnthac...@gmail.com> wrote: > > > Well, there are two other options: > 1) Adding the ability to do BASE_CUSTOM for FT_FLOAT and FT_DOUBLE > 2) Declaring as FT_[U]INT32 with BASE_CUSTOM, and do the type punning in the > custom function, as done in > tvb_get_nttohieee_float() in tvbuff.c for when FT_FLOAT is used anyway. For > bonus points, implement (or export > and make no longer static) get_ieee_float() in the same that exists for VAXen > and other non IEEE754 floating point > machines where simple type punning won't work. > > John Thacker > > > > On Mon, Jul 6, 2020 at 5:51 PM Jaap Keuter <jaap.keu...@xs4all.nl > <mailto:jaap.keu...@xs4all.nl>> wrote: > Hi, > > So, you want to keep this function call: > > proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, > ENC_BIG_ENDIAN); > > with this header field definition: > > { &hf_conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT, > BASE_NONE | BASE_UNIT_STRING, &units_degree_degrees, 0x0, NULL, HFILL }} > > but have it output "Unspecified Location" in case the value is +/- infinity. > > Unfortunately the use of BASE_CUSTOM is not available for FT_FLOAT, so I see > no other way than this: > > if (isinf(pmu_lat)) { > proto_tree_add_float_format_value(wgs84_tree, hf_conf_pmu_lat_unknown, > tvb, offset, 4, INFINITY, unspecified_location); > } else { > proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, > ENC_BIG_ENDIAN); > } > > and these header field definitions: > > { &hf_conf_pmu_lat_unknown, { "PMU Latitude", "synphasor.conf.pmu_latitude", > FT_FLOAT, > BASE_NONE, NULL, 0x0, NULL, HFILL }} > { &hf_conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT, > BASE_NONE | BASE_UNIT_STRING, &units_degree_degrees, 0x0, NULL, HFILL }} > > Now at least the field abbrev "synphasor.conf.pmu_latitude" has a constant > type FT_FLOAT. > > I hope I got this right. > Jaap > > > On 7/6/20 10:12 PM, Елисеев Дмитрий Алексеевич wrote: >> Hello, Jaap Keuter! >> I made some fast cheks and need some help. >> I need some function like: >> proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, >> ENC_BIG_ENDIAN); >> { &hf_conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", >> FT_FLOAT, >> BASE_NONE | BASE_UNIT_STRING, &units_degree_degrees, 0x0, NULL, >> HFILL }} >> >> witch replace Infinity with text: "Unspecified Location" >> >> С уважением, >> >> Дмитрий Елисеев >> инженер >> сектора испытаний систем управления и автоматики >> АО «НТЦ ЕЭС» >> т: 29-29-499 доб. 214 >> a: ул. Курчатова, д. 1, лит.А , Санкт-Петербург, Россия, 194223 >> e: elis...@ntcees.ru <mailto:elis...@ntcees.ru> >> >> >> От: Jaap Keuter <jaap.keu...@xs4all.nl> <mailto:jaap.keu...@xs4all.nl> >> Кому: Dmitriy Eliseev <elisee...@ntcees.ru> <mailto:elisee...@ntcees.ru>, >> Developer support list for Wireshark <wireshark-dev@wireshark.org> >> <mailto:wireshark-dev@wireshark.org> >> Отправлено: 06.07.2020 19:10 >> Тема: Issues in synphasor dissector >> >> Hi Dmitriy, >> >> There are still some issues with the synphasor dissector. There are a number >> of fields with the same field abbreviation, but incompatible type. >> These are lines from the 'conflict check' run by the buildbot: >> >> 'synphasor.conf.chnam_len' exists multiple times with NOT compatible types: >> FT_STRING and FT_UINT8 >> 'synphasor.conf.phasor_flags' exists multiple times with NOT compatible >> types: FT_UINT16 and FT_BOOLEAN >> 'synphasor.conf.pmu_latitude' exists multiple times with NOT compatible >> types: FT_STRING and FT_FLOAT >> 'synphasor.conf.pmu_longitude' exists multiple times with NOT compatible >> types: FT_STRING and FT_FLOAT >> 'synphasor.conf.pmu_elevation' exists multiple times with NOT compatible >> types: FT_STRING and FT_FLOAT >> >> https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/12010/steps/conflict%20check/logs/stdio >> >> <https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/12010/steps/conflict%20check/logs/stdio> >> >> >> You seem to be knowledgeable about this protocol and dissector. Would you be >> able to address these reported issues? >> >> Thanks, >> Jaap >> > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org>> > Archives: https://www.wireshark.org/lists/wireshark-dev > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org > <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > 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 <wireshark-dev@wireshark.org> 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
