[BUG] - Incorrect test case

[abhiperfect]

LeetCode Username

abhi_perfecct007

Problem Number, Title, and Link

152, Maximum Product Subarray, https://leetcode.com/problems/maximum-product-subarray/

Bug Category

Incorrect test case (Output of test case is incorrect as per the problem statement)

Bug Description

"The test cases are generated so that the answer will fit within a 32-bit integer. However, the result of the following test case does not meet this condition: nums[] = [0,10,10,10,10,10,10,10,10,10,-10,10,10,10,10,10,10,10,10,10,0]"

Language Used for Code

C++

Code used for Submit/Run operation

class Solution {
public:
    int maxProduct(vector<int>& nums) {
        int n = nums.size();
        long long pre = 1;
        long long suf = 1;
        long long maxProd = INT_MIN;

        for (int i = 0; i < n; ++i) {
            if (pre == 0)
                pre = 1;
            if (suf == 0)
                suf = 1;
            pre = pre * (long long)nums[i];
            suf = suf * (long long)nums[n - 1 - i];

            maxProd = max({maxProd, pre, suf});
        }

        return maxProd;
    }
};

Expected behavior

I expected the solution to pass all test cases since it was clearly mentioned in the problem that "The test cases are generated so that the answer will fit in a 32-bit integer."

However, a runtime error occurred:

Line 14: Char 23: runtime error: signed integer overflow: -1000000000000000000 * 10 cannot be represented in type 'long long' (solution.cpp)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior solution.cpp:14:23

If I use double instead of long long, all test cases pass.

Screenshots

Additional context

No response

[exalate-issue-sync[bot]]

Winston Tang commented: Dear abhi_perfecct007,

Thank you for reaching out. After reviewing your report, it appears the issue you're encountering stems from an integer overflow occurring within your code operations. While it's stated in the problem that the final result will fit within a 32-bit integer, this doesn't guarantee that all intermediate calculations within your specific solution will also fit.

The runtime error was generated due to a sign overflow. This is common when working with larger integers and can be remedied by using a different approach. Please consider revisiting your algorithm to ensure that the intermediate calculations do not exceed the range of the types you're using.

Remember that LeetCode problems are designed to test varying degrees of understanding in computer science concepts, including the ability to comprehend and account for language-specific intricacies like integer overflow.

Please do not hesitate to reach out with further questions or clarifications.

Happy coding!

Best, LeetCode Support Team

[BrandonStegall]

Winston Tang commented: Dear abhi_perfecct007,

Thank you for reaching out. After reviewing your report, it appears the issue you're encountering stems from an integer overflow occurring within your code operations. While it's stated in the problem that the final result will fit within a 32-bit integer, this doesn't guarantee that all intermediate calculations within your specific solution will also fit.

The runtime error was generated due to a sign overflow. This is common when working with larger integers and can be remedied by using a different approach. Please consider revisiting your algorithm to ensure that the intermediate calculations do not exceed the range of the types you're using.

Remember that LeetCode problems are designed to test varying degrees of understanding in computer science concepts, including the ability to comprehend and account for language-specific intricacies like integer overflow.

Please do not hesitate to reach out with further questions or clarifications.

Happy coding!

Best, LeetCode Support Team

If the problem only stated that the final result will fit within a 32-bit integer, I think you'd have a point, but the constraints also clearly state "The product of any prefix or suffix of nums is guaranteed to fit in a 32-bit integer." I don't see how that constraint could possibly be interpreted in any other way than the intermediate calculations also being guaranteed to fit within a 32-bit integer.