-1

Consider the following code

#include <bits/stdc++.h>

using namespace std;

using ll = long long;

int main() {
  ios::sync_with_stdio(false);
  cin.tie(0);
  int n, k;
  cin >> n >> k;
  vector<int> a(n);
  int sum = 0;
  for (auto &it : a) {
    cin >> it;
    sum += it;
  }
  cout << sum << "\n";
  for (int i = 0; i < n; i++) {
    cout << a[i] << " ";
  }
  cout << endl;
}

Input like (or anything greater than INT_MAX into k)

5 1234567891564
1 2 3 4 5

makes the program print

0
0 0 0 0 0

What actually happens? We don't use the value of k at all.

migo101
  • 1
  • 2
  • `cin >> k` fails – user253751 Jun 02 '22 at 08:21
  • @user253751 Does this failure discard the next inputs? – migo101 Jun 02 '22 at 08:23
  • The stream is in fail-state until you release it from bondage. And since you never actually check it (success/fail stream state), you never know it failed, and end up scratching you head on input that didn't in-fact happen. – WhozCraig Jun 02 '22 at 08:24
  • Welcome to StackOverflow. Have a look [here](https://stackoverflow.com/questions/18728754/checking-cin-input-stream-produces-an-integer). – PhilMasteG Jun 02 '22 at 08:25
  • @migo101 no, the input is still there waiting for you to read it, which you don't. Your program keeps failing to read the same bad input over and over. – user253751 Jun 02 '22 at 08:25
  • Side note: https://stackoverflow.com/questions/31816095/why-should-i-not-include-bits-stdc-h – Jabberwocky Jun 02 '22 at 08:27
  • @Jabberwocky Is it also a bad practice in competitive programming? – migo101 Jun 02 '22 at 08:29
  • @migo101 it is bad practice, period. Don't do it. Whoever told you to do this should be banned from teaching C++ for the rest of his life – Jabberwocky Jun 02 '22 at 08:30
  • @Jabberwocky I think in competitive programming nobody cares as long as the code works and is fast. Until they try to compile it on Windows where the header file doesn't exist... – user253751 Jun 02 '22 at 08:31
  • @user253751 on Windows or on the next version of gcc, clang or whatever – Jabberwocky Jun 02 '22 at 08:32
  • While this particular program might not be having issues with integer overflow, in gcc it is possible for an integer overflow to cause arbitrary memory corruption even in cases where the result of the calculation is simply stored into an automatic-duration `unsigned int` whose value would never be read. – supercat Jun 03 '22 at 16:53

1 Answers1

7

There is actually no integer overflow in your code. Well in a wider sense it there is, but in a more narrow sense integer overflow would happen for example with:

int k = 1234567891564;

What actually happens is that in this line

cin >> n >> k;

operator>> tries to read a int but fails. 1234567891564 is never actually assigned to k. When reading the input fails 0 will be assigned. Hence k comes out as 0.

Once the stream is in an error state, all subsequent calls to operator>> will silently fail as well. You should always check the state of the stream after taking input. For example:

 if (std::cin >> n) {
     // input succeeded use the value 
 } else {
     // input did not succeed. 
     std::cin.clear(); // reset all error flags
 }        
463035818_is_not_an_ai
  • 109,796
  • 11
  • 89
  • 185