On Wed, Jul 18, 2012 at 5:41 PM, Ted Kremenek <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
