-6

Why this:

#include <iostream>
using namespace std;

int main() {
    int a[1] = {0};
    a[2048] = 1234;

    cout << a[2048] << endl;

    return 0;
}

does not give any compile-time error? (gcc 4.9.3)

vladon
  • 8,158
  • 2
  • 47
  • 91
  • 2
    Why would it? The compiler doesn't give two hoots whether you want to shoot yourself in the foot. *You* chose to invoke *undefined behavior*. You reap what you sow. If it seems to work you were (un)lucky. – WhozCraig Jul 30 '15 at 05:12
  • With clang, there is a warning called array-bounds which is doing exactly this. – Kevin MOLCARD Jul 30 '15 at 06:28

2 Answers2

2

Because this is legal C++.
You can try to dereference any pointer, even if it's not allocated by your program, you can try to access any cell of an array, even if it is out of bounds, the legality of an expression doesn't depend on the values of the variables involved in that expression.
The compiler doesn't have to run any static analysis to check whether you'll actually cause undefined behaviour or not, and shouldn't fail to compile if it assumes that you will (even when it is obvious that you will).
The problem is that you can't check all possible array access at compile-time (that would be way too expensive), so you'd have to arbitrarily draw a line somewhere (the problem being the word "arbitrarily", that wouldn't fit well in the standard).
Hence, checking that you won't cause undefined behaviour is the responsability of the programmer (or of specific static analysis tools).

Caninonos
  • 1,214
  • 7
  • 12
  • Is checking array access with a constant for an index really that expensive? It's true that this is valid, but I agree with the OP that a warning would be nice. – Mr Lister Jul 30 '15 at 05:33
  • No it isn't. However if you can check that, you could argue that you could check everything which is constexpr. Then you could argue you could perform basic static analysis to further improve this. Then you could argue you could run a full-fledged static-analysis tool because that would give the best results. The problem is that the standard doesn't have the right to decide the compromise between compilation time/static analysis for you. You can still statically check your code, but you'll have to use a static analysis tool for that, it's not the compiler's job. – Caninonos Jul 30 '15 at 05:42
  • Still, i have to admit, a warning would be interesting to have, as long as the static analysis can be disabled with options and that it isn't a hard error. But again, it's just adding a static analysis tool on top of the compiler. The standard doesn't have the right to ask each compiler to implement such a static analysis tool, it must be optional. – Caninonos Jul 30 '15 at 05:48
1

Access to out of array range does not give any error

This is just because you were unlucky. :) What you can call it is "Undefined Behavior". Compiler is not doing any bound check on arrays, and what you are trying to do in statement a[2048] = 1234;is to write a memory location on stack, which is unused.

Nishant
  • 1,635
  • 1
  • 11
  • 24