1) Is the pointer overflow overflowing an unsigned integer? That is, is it valid to check the fact of overflow after overflow?

For example, according to the Standard, an overflow of a signed integer is UB , because of this, it is necessary to check for possible sign overflow before it occurs.

2) Is an overflow check necessary?

For example, quite often there is a need to work with data through a pointer to an array, the size of the element and the number of elements.

For example, the following situation definitely needs to check that multiplying size by count does not lead to an integer overflow of type size_t .

const void *const data = malloc(size * count);

I suspect (but not completely sure) that the following situation with a pointer also needs to be checked:

 void f(const uint8_t *const _data, const size_t _elem_on_record, const size_t _records_count) { const size_t record_size = sizeof(uint8_t) * _elem_on_record; // Контроль возможного переполнения record_size. // ... for (size_t r = 0; r < _records_count; ++r) { const size_t bias = r * record_size; // Контроль возможного переполнения bias. // ... const uint8_t *const select_record = _data + bias; // Возможно переполнение select_record, даже если // переполнения bias не возникло... f2(record); } }

I understand that the select_record overflow is responsible for the one who called the f1 function. But I would like to protect myself from the situation when select_record is full. This is important for security, for example, server.

Tell me, is it really necessary to control a possible pointer overflow, and how to do it correctly?

  • Comments are not intended for extended discussion; conversation moved to chat . - Yuriy SPb ♦

2 answers 2

In C, there is no and cannot be the concept of "pointer overflow". And, of course, there is no "whole" pointer.

Arithmetic and ordering comparisons of pointers in C are defined only within the elements of one array plus an imaginary element following the last element of this array. Attempting to create a pointer that goes beyond this range leads to indefinite behavior (it doesn't matter if this overflow occurred or not). Within this range, of course, no “pointer overflow” can arise: an array cannot exist, access to elements of which causes some kind of address "overflow", because access to array elements in C itself is conceptually implemented through pointer address arithmetic.

If you work with an array (memory block) allocated with standard language tools, then you do not need to worry about any "overflow of pointers".

  • Comments are not intended for extended discussion; conversation moved to chat . - Yuriy SPb ♦

The pointer is not an unsigned integer. Support for address arpimetics does not guarantee that the pointer is an integer. As an example, you can recall the addressing in the form of a segment register + offset in a segment.

If you really need to verify the validity of address arithmetic, use the functions IsBadReadPtr and IsBadWritePtr .