nus-se-script
commented
5 months ago Team's Response
Rejected for same reason as #854.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Integer overflow for all whole number outputs
[original: nus-cs2113-AY2324S2/pe-interim#777] [original labels: type.FunctionalityBug severity.High]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Clearly an example of extreme user behavior. Noted on the attempts to try some sort of input injection attacks as well 🙄.
Anyway, there is obviously no integer overflow in this case. The extremely large threshold value, which you tried to input, was correctly caught by the application and treated as invalid.
How can you therefore say that there is an overflow when your input has been invalidated and not accepted by the application?
High bug severity is completely unjustified and unwarranted as well, since there is no concrete proof of "integer overflow" in your attached screenshot. I'll reduce its severity to Low.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.Rejected`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
When updating an existing item with a very large quantity, instead of throwing an error like the number is too big, it just says number has to be whole number instead.