-1

Please, can some one tell me what's wrong with this code?

#include <iostream>
using namespace std;
int main() {
    int a[3], i;
    for(i = 0; i <= 3; i++ )
        {
            a[i] = 0;
            cout << "i = " << i << endl;
        }
    return 0;
}
Nam Time Times
  • 1
  • 1
  • 3
    The index of the array is from 0 to 2, so you're getting out of the range. Change the loop to `for(i = 0; i < 3; i++ )`. – songyuanyao Feb 19 '21 at 03:41
  • 1
    Array indexing starts at zero, and the maximum index for an array with three elements is two i.e. `a` has elements `a[0]`, `a[1]`, and `a[2]` but no `a[3]`. Your loop is therefore going one element too far, and modifying the non-existent `a[3]`. Change the end condition in the loop from `i <= 3` to `i < 3` to fix that. – Peter Feb 19 '21 at 03:47
  • 3
    What makes you think something is wrong? Please describe the problem you're having exactly. – cigien Feb 19 '21 at 04:27
  • 2
    I might argue that there is nothing wrong with this code, provided that the intent of the code is to invoke undefined behavior. :) OK, calm down. My point is that without a description of what is right (i.e. the expected results), there is no reason to assume that the actual results are wrong. That brings us back to cigien's comment and the need for more text to make this question useful to others. – JaMiT Feb 19 '21 at 05:51

1 Answers1

1

The array length for this code is only 3 but the for loop executes 4 times since the loop executes from 0 to 3. The value of i will look like this:

i = 0
i = 1
i = 2
i = 3

Since the array a[3] length is 3, but you tried putting 4 elements in it ofcourse it will show an error:

*** stack smashing detected ***: terminated
Aborted (core dumped)

Fixes

Try to change the array length or the loop condition.

Maverick Fabroa
  • 1,105
  • 1
  • 9
  • 15
  • Putting four elements into an array does not necessarily "show an error". The behaviour is undefined. There are a lot of bugs in code related to falling off the end of an array, and modifying something else, but not necessarily reporting an error. Other symptoms - which a lot of C++ developers have experienced the hard way - is such a loop appearing to work without error, but some other variable in some other unrelated code - that happens to occupy the memory immediately past the end of the array - mysteriously changes. Such bugs do occur, and can be quite difficult to track down. – Peter Feb 19 '21 at 03:56
  • "it will show an error" - If only this were true. The behavior is undefined and the implementation is not required to produce a runtime error. More likely, it will either work (when you test it) or you'll get some weird behavior (when you ship it to customers). – Bungo Feb 19 '21 at 03:57
  • 1
    @Bungo - The fun (ahem!) cases are when it works in your testing AND exhibits weird behaviour for the customer. – Peter Feb 19 '21 at 04:01
  • @Peter - Yep, that's what I meant. Great fun to troubleshoot those kinds of bugs... Btw, it's worth noting that undefined behavior due to incorrect indexing is not unique to plain old C-style arrays but applies equally to `std::vector` and `std::array` when using `operator[]` (as opposed to `.at()`). I've known relatively senior developers who did not realize this. – Bungo Feb 19 '21 at 04:05
  • 1
    @Bungo - that's one reason I prefer iterators over array indexing where possible. Doesn't eliminate the possibility of running too far (e.g. and dereferencing the end iterator) but it's easier to make such errors with indexing. Even better is to avoid using raw arrays or pointers at all, and (C++11 and later) use a range-based `for` loop (it's then challenging to *deliberately* run past the end of a container, let alone do it accidentally). – Peter Feb 19 '21 at 04:16