Comment # 4
on bug 9130
from Michael Mann
(In reply to comment #3)
> We have been working on this bug for a class. The crash continues to happen
> when a range of one value is used, placed at the top of the list and then
> Statistics is used. Our team added an error control statement for input of
> a single value. However, when the range is enter for a single value (i.e
> 64-64) the value is stored as a single "64" and the crash will still occur.
What version are you using? It doesn't crash for me on 1.10.3 (where the
bugfix was backported to) or SVN.
> Two questions:
Is the single value range intended to be implemented or
> should the value be stored as a range?
Part of the change in r52679 was to treat a single value as a "range". Parsing
of the value will still create a single value, but it will be treated as a
range when checking for matches.
> And, is the range meant to
> maintained in a proper order (that is smaller ranges included after that
> range, which encompasses it) such as the post by Michael Mann suggests?
> Thanks for the help.
Range doesn't need to be in "proper order" if there is no overlap. I assume
that "performance reasons" dictated just adding a count to the first range
matched (and just break out of the loop checking ranges). If you add the
assumption that range will be in proper order you could more easily have
overlapping ranges without a big performance hit.
You are receiving this mail because:
- You are watching all bug changes.