A vtable index is same as a function name, it's determined at compile time and won't change and of course won't be over flow. If you debug to see a virtual member function pointer, you will find it's some vtable index instead of pointer to memory.

The compiler knows the offset of a function address in the vtable the same way it knows the offset of a local variable address in the stack or the address of a non-virtual function in memory.

If you change the order of virtual functions in a class (for example, adding a new virtual function in the middle) and recompile only part of the program that used that object but not others, you will probably get a crash.  That's called an "ABI mismatch" because the vtable offsets are hard-coded, and it's the bane of C++ developers.  It's a frequent problem using Microsoft Visual Studio, which does a poor job of dependency tracking (and it only has one job, so go figure) and the fix is to force-rebuild the entire project.  It's also a problem with .so files on Linux when developers do not follow best practices (and many believe they know better, so go figure).

Just as an aside, the C++ standard doesn't require a vtable, it simply requires some method of virtual dispatch.

In practice, most, if not all, compilers implement this using a vtable, but in theory, they are free to use whatever method they desire in the background, as long as virtual dispatch still works.