Le 20 févr. 2014 19:55, "Hadriel Kaplan" <hadriel.kaplan@xxxxxxxxxx> a écrit :
>
>
> 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.
Hi,
It can create issues (as you can guess) and this is tracked by bug 2402.
Pascal.