On 2013/08/21 19:28:35, felix8a wrote:
lgtm
vague meta-concern: I find it very hard to audit the scanner rules
meaningfully,
and I'm not sure what would help. it seems that there are two types of
bugs we'd
care about:
1. wrongly marking a bad situation as ok.
2. failing to exercise a function in some meaningful way.
and I have little confidence I'll notice either type of bug. I think
this is the
third or fourth time I've looked at the scanner in detail, and it
hasn't really
gotten easier with practice.
I agree — I see it as a messy solution to a messy problem. A couple of
thoughts:
1. I'm planning to refactor to always group together one type of
object's annotations, rather than having the args separate from the
frozenness and the obtainInstance. (The 'Ref' thing is part of that — to
have a uniform vocabulary for pointing at objects, not tied to
individual lookup tables.)
2. This particular change is actually about automatically detecting
failure to exercise a function — if all the calls to it throw, then the
successful case is not being exercised (or it is broken).
I'd love to hear any ideas for better, less error-prone language for
expressing the rules. (Note that one of the constraints is that we don't
exercise anywhere near all likely-interesting cases, because that would
take too much time. A lot of the rules could be a lot more precise,
otherwise.)
https://codereview.appspot.com/13024043/
--
---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
