Is there a chance to increment pass the entire end if Im unlucky?
Yes. C++ doesn't do bounds checking. You can set a pointer to any value you want and try to access it.
Most hardware/operating system combinations will restrict the memory that a process can access. So if you try to access memory that hasn't been allocated to the process, it will crash, usually with a "segmentation violation" or "bus error."
std::vector<>'s at() method checks to see if the index is in range, so you might consider using that if it works for you. Otherwise it's like Keskiverto said: keep track of the start & end of the block and do the check yourself.
> after incrementing pointers I want to make sure that the pointer is still within its range
> How can I check that a pointer/value exists inside the same memory block as another pointer/value?
Use std:less<> for example: if( std::less<>{}( ptr < (mem_block_base+mem_block_sz) )
Modern compilers take advantage of undefined behavior and optimize accordingly. If they see a relational comparison between pointers, they are permitted to assume that the pointers point into the same aggregate or array (or one past the last element of that array), because any other type of relational comparison is undefined. https://devblogs.microsoft.com/oldnewthing/20170927-00/?p=97095
A specialization of std::less for any pointer type yields a strict total order, even if the built-in operator< does not. The strict total order is consistent among specializations of std::less, std::greater, std::less_equal, and std::greater_equal for that pointer type, and is also consistent with the partial order imposed by the corresponding built-in operators (<, >, <= and >=). https://en.cppreference.com/w/cpp/utility/functional/less#Specializations
you should always know how big a pointer is. If you allocated it, you should know its size. If you are losing track of this, you have a bigger problem; you can fix it maybe with some checks and extra code but you should not need to: you should instead focus on keeping track better, and if that means making your own little pointer management class to do it, you can do that (put in its size and only let the class get/delete/ memory and overload [] to check any screwups).
You can also just avoid increment of pointers and use [] exclusively. Its easy to see that you messed up if a[x] was out of bounds and your debugger tells you that x is 100000000 and a is [10] sized. Its difficult to see in a debugger that 0xffaa12349275C is valid or not when all you have is your incremented pointer (it will tell you it is no good, but it won't tell you how many times you incremented it). There is nothing wrong with pointer increment / pointer math apart from its debug friendliness, but that is enough of a hassle that I avoid both most of the time.