On Feb 19, 2014, at 7:03 PM, Evan Huus <eapa...@gmail.com> wrote: > You can reuse a single "spare" field for all of these bytes, and they > would only cause a single entry in the filter expression dialog. I > suspect this is the best answer.
Speaking of duplicating field abbreviation names, I was going to "fix" bug 9790, by preventing Lua-based field creators from duplicating existing field abbrev names. (but give them a way to force doing so if they really mean it) So I was curious how many C-code fields are duplicated, and I was shocked to find 13,970 fields are dups. Of those ~14k dups, 1401 of them don't register the same ftype as the original field. Ignoring differences in integer size differences (ie, FT_UINT8 vs. FT_UINT16), there are still 842 that use different ftypes. 435 of them were not FT_NONE as one of the field ftypes. In other words, 435 are very different ftypes. Isn't that going to cause problems in filters? At least I seem to get weird display filter behavior when two fields of the same name are very different types. I have pretty output listing all the above mismatches, if anyone cares to see it. -hadriel ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
