On Feb 19, 2014, at 7:03 PM, Evan Huus <eapache@xxxxxxxxx> 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
