I may be remembering this incorrectly, but vec.at(x) is safe (i.e. does bounds checking), but vec[x] is not safe.
I'm going to try some test code here and check, but I'm pretty sure vec[x] will happily overflow.
Edit: https://gist.github.com/tonyarkles/e702e4d5b530a9b7cd3fc9837...
Definitely overflows and segfaults while unwinding the stack (presumably while deallocating the stack-allocated vector)
What your example shows is an attempt to access a vector element that does not exist (std::out of range). And, that is undefined behavior and is documented.
Also, that code is 95% C (not C++). Even the includes and prints are C. Pure, idiomatic C++ would use iostream rather than stdio.h, and a vector iterator to access the elements rather than looping over the vector (in C like fashion) using an integer (which is unrelated to the vector) in an effort to access elements via index.
His example shows the precise opposite: the vector didn't grow automatically. Instead, memory outside the vector bounds was accessed, i.e., the vector overflowed.
Yes, idiomatic modern C++ makes that less likely, by reducing the use of explicit indexes. Even then, you still can overflow a vector with innocent-looking code.
In C, buffer overruns are undefined behavior and are documented. Back to square 1.
g++ -Wall -pedantic vec.cpp
Also, it is relatively straight-forward to compile C code with a C++ compiler and adopt C++ constructs while throwing out all the old insecure C constructs. Doing this would vastly improve security and is achievable in a short period of time with little or no performance loss (it will probably run even faster).
Yet, all I read about on web forums such as HN are unattainable suggestions such as re-write X in the newest, non-standard, corporate backed/controlled language that isn't nearly as tested nor as performant as ISO Standard C++. Maybe it's just me, but I find these suggestions to be totally out of touch with reality and really uniformed about the vast differences between C and C++.