[cfe-commits] [Patch] -Wduplicate-enum which fixes PR6343

[Sean Silva]

Why not just keep a set containing all previously seen values? Then
you can find duplicates with a linear scan.

--Sean Silva

On Wed, Jul 18, 2012 at 6:11 PM, Richard Trieu <rtrieu at google.com> wrote:
> On Wed, Jul 18, 2012 at 5:41 PM, Ted Kremenek <kremenek at apple.com> wrote:
>>
>> Hi Richard,
>>
>> I think this checking is quadratic, n(n+1)/2.
>
> Yes it is.  It does perform a check between each enum in the worst case.
>
>>
>>  This might be fairly expensive on a large set of enums.  Do you have any
>> performance numbers?
>
> I haven't run any performance tests.  I will try running some when I get the
> chance.
>
>>
>>  I agree that it is a good checking, but the way it is implemented is
>> likely to be noticeably slow on some (important) cases.
>
> How many elements in an enum would be in these important cases?
>>
>>
>> Ted
>>
>> On Jul 18, 2012, at 4:46 PM, Richard Trieu <rtrieu at google.com> wrote:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=6343
>>
>> Warn on enum elements that are assigned values already in use.  This is
>> based on the misconception that elements not given a value will be given the
>> next smallest, unused value.  Instead, elements are assigned 1 more than the
>> previous value.  Some example code this warning will catch:
>>
>> enum { A, B, C, Aref = A, count };
>> Both B and count will have value 1.
>>
>> enum { A, B, C, D = -1, E, F };
>> A = E = 0
>> B = F = 1
>>
>> This warning found one such issue in LLVM that was fixed in r160465.
>> <duplicate-enum.patch>_______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>