Почему нет ругани на модификацию стороннего куска памяти?

Question

[prometian]

Добрый день!
Следующий код объявляет и инициализирует массив, а так же указатель на массив.
Изначально указатель стоит на начале массива и увеличивается пока не дойдет до адреса последнего элемента.
Почему, если мы объявили 500 элементов, а первый начинается с индекса 0, программа спокойно дает нам выйти за пределы массива и модифицировать память?
Правильно ли я думаю что в случае с указателями никакой проверки не проводится вообще и ошибка может возникнуть, а может и отсутствовать, а правильным должно быть условие while (pTmp != &tmp[499]) ?
Каким образом можно проверить что участок памяти доступен для записи не вызывая ошибку или try catch единственный способ?

int32_t tmp[500];
int32_t * pTmp = tmp;

{
for (int i = 0; i < 500; i++)
{
tmp[i] = i;
}
}

while (pTmp != &tmp[500])
{
*pTmp = *pTmp * 10;

pTmp++;
}

_getch();
return 0;

Answer 1

[Александр Ручкин]

Запись по невалидному указателю - это UB (undefined behavior), т.е. по стандарту произойти может что угодно. На деле просто пишется туда, куда сказали, что может вызвать как структурное исключение (SEH, не путать с обычными исключениями C++) на Windows или SIGSEGV на Unix'ах, а может и не вызвать, если по данному указателю запись возможна. Т.о. try-catch не решение по двум причинам:
1. Исключение даже если и будет, то не C++ (хотя, к примеру, студия позволяет SEH'и ловить "обычным" catch)
2. Исключение не гарантировано

Проверять, что память доступна для записи в общем случае бессмысленно, так как она вполне может быть доступна, но по адресу лежит не массив, а какие-то другие данные, которые тем не менее можно перезаписать, поломав программу. Решение заключается в том, чтобы не писать туда, куда не нужно, т.е. сводить к минимуму манипулирование голыми указателями без должной осторожности и понимания.

Comments

[prometian]

Благодарю за развернутый ответ.
А правильно ли вычислять последний адрес: &tmp + количество элементов*sizeof(type) ?
Спрашиваю потому что пробую играть с void *

[Александр Ручкин]

Смотря какой тип у &tmp. Указатель смещается не на байты, а на элементы, т.е. ptr + n смещается на n * sizeof(T) байт сам по себе, где T * ptr. Т.о. ptr + n ≡ reinterpret_cast(reinterpret_cast(ptr) + n * sizeof(T)). void * же смещать нельзя, сначала его надо к чему-то преобразовать.

[Александр Ручкин]

Т.е. в вашем исходном примере последний адрес: tmp + 500 (tmp в данном случае эквивалентно &tmp[0]). Также надо иметь в виду, что sizeof(tmp) - размер массива в байтах, а не в элементах, т.е. 500 * sizeof(int32_t) в данном случае.

[prometian]

Да, это опытным путем проверил. Про элементы спасибо, видимо не внимательно читал документацию (там как раз и был крах у меня).
Про void * знаю, очень понравилось играть с int64 как двумя int32, возможности кажутся безграничными =)

Про void *:
__int64 buffer = 1024;
void * data = malloc(buffer*sizeof(__int64)); // память по 1024 элемента размером 8 байт
тогда конечный элемент void * end = (__int64 *)data + 1024; правильно я понял?

[Александр Ручкин]

Точнее не конечный, а следующий за ним, т.е. этот указатель уже указывает за пределы выделенной памяти. Думаю, вы это и имели в виду.

[prometian]

Нет, как раз имел ввиду конечный, спасибо за поправку, вот у меня и получалось обращаться к неправильному блоку памяти. Элемент от которого начинается - тоже область с некоторым значением.
Спасибо за урок, разобрался.
Добавлю что если следом вызывать free(data); то можно словить крах, т.к. указатель уже находится за пределами выделенного блока, поэтому я сохранял стартовый адрес.
Вопрос, если я сохранил адрес начала чтобы сделать data = start; free(data); мог ли я сразу делать free(start); ? ведь идет ссылка на выделенный блок

[Александр Ручкин]

В C++ это обычная практика - начало указывает на первый элемент, а конец - за последний. Это касается указателей и итераторов. Т.е. начало - вполне валидный указатель, между началом и концом - валидный, а вот сам конец - это уже невалидный.
По поводу free(start) - сделать так можете, но получите то же UB, ибо этот блок будет помечен, как свободный. То, что временно он будет ничем не занят и туда можно будет писать - особенность, ничем не гарантированная. Т.е. это почти то же самое, что писать наугад.
free/malloc, new/delete, new[]/delete[] - парные функции и операторы, они обязаны вызываться именно в паре (т.е. если malloc, то free, если new, то delete, если new[], то delete[]) и ровно для того указателя, который вернули, а не для какого-то, который лежит внутри той области, которую они выделили.
malloc(size) возвращает указатель на начало области памяти, и именно это значение указателя должно быть передано во free по окончании работы с памятью, а какие вы в период работы заводите указатели внутрь этого блока - значения не имеет

[Александр Ручкин]

Стоит отметить, что в случае с new/delete необходимо ещё и сохранять тип указателя, т.е. void * p = new SomeClass(); delete p; - UB. На деле не будет вызван деструктор, что может повлечь различные последствия в зависимости от того, чем этот деструктор занимается, но это особенность реализации, на которую полагаться не стоит. Можно только передавать указатель на базовый класс, если деструктор виртуален. Что касается new[]/delete[], то там тип должен быть строго тот же.

[prometian]

Но я верно написал что по окончании работы скорее всего data будет ссылаться на end, поэтому чистить блок нужно через free(start); ? Ведь это и есть начало блока. Хорошо, а разметку блока можно как-то посмотреть или это просто на программисте лежит? Блок разметили, начало и размер храним. Тогда как free знает сколько нужно очистить. Вот я занял блок 1024 байта, как free знает что нужно очистить именно их или получается чистится только первый элемент и нужно вызывать free в цикле для всех разыменовывая указатель?
Например:

void *data = nullptr;
void *end = nullptr;

data = malloc(sizeof(int)*20);

if (data == nullptr)
{ return 0;}
void *start = (int *)data;
end = ((int *)data + 20);

for (int i = 0; i <= 19; i++)
{
*(int *)data = i;
data = (int *)data + 1;
}

data = (int *)start;

while (data != end)
{
std::cout << *(int *)data << std::endl;
data = (int *)data + 1;
}

free(start); // т.к. если вызову free(data); то огребу ошибку, т.к. этот блок не мой. Но при этом data != nullptr, а вот start как раз очистился, только теперь вопрос в том очистился ли весь блок в 80 байт или только первые четыре байта.

[prometian]

А "delete p; - UB", потому что мы удалили саму ссылку, но не объект или вообще на совести компилятора, тут как раз вроде проще. Это же будет утечка памяти, правильно?

[Александр Ручкин]

delete вызывает деструктор соответствующего объекта, а затем освобождает память, при этом если тип не соответствует исходному, будет вызван не тот деструктор, либо в случае с void * не будет вызван никакой. Память при этом освобождена будет, но только та, которая выделена была под сам объект. Если этот объект имел внутри себя ссылки на какие-то другие объекты, под которые была выделена память при его создании, они не будут уничтожены (так как это происходит в деструкторе) и не будет освобождена память под них.
Т.е., упрощённо, если объект содержит внутри себя только пару int, то ничего страшного не будет, а если он внутри содержит std::vector, который сам ссылается на выделенную под массив память, то деструктор std::vector'а не будет вызван и память под массив не будет освобождена.

[Александр Ручкин]

free знает потому, что менеджер памяти хранит информацию относительно длины выделенного блока, в цикле его звать не надо
Т.е. достаточно

void * p = malloc(...);
void * data = p;
// используете data, контролируя его невыход за пределы блока
free(p);

[prometian]

Да, проверил экспериментально, все получилось. При этом я передал во free указатель на начало блока (т.е. start), а дальше просто прошелся указателем data по предыдущим значениям, но почему при этом start не стал равен nullptr?
free только пометил блок как чистый и заполнил его мусором, но указатели все еще рабочие, это нормально?

[Александр Ручкин]

А почему start должен стать nullptr? free не меняет сам указатель, а освобождает память. Указатель - это грубо говоря просто число, вы передали его во free, память по этому адресу освободилось, но само-то число у вас осталось то же. free также не заполняет мусором, хотя, возможно, делает это в debug'е для диагностики. Что значит "указатели рабочие"? Вы можете написать даже так:

char * p = 0;
p = p + 12345;

Это не делает указатель "рабочим", это просто указатель куда-то там, хотя он и не nullptr. В вашем случае после free все указатели в ту область памяти так и остаются указателями в ту же область, но чтение/запись оттуда/туда уже приведёт к UB - т.е. может и сработать, а может и нет.

[prometian]

Получается что после такой чистки имеет смысл принудительно присваивать указателям nullptr, чтобы в дальнейшем избегать проблем. Правильно?
Т.е. пользовались мы указателем, затем блок памяти почистили, следом ему присвоили nullptr и дальше можем спать спокойно.

[prometian]

Я считал что раз передается указатель, то free очищая память должна его сослать в nullptr (мне казалось такое поведение логичным, чтобы программа не сбоила дальше).

[Александр Ручкин]

Некоторые так и делают. Можно завести свою функцию, которая будет выставлять указатель в nullptr. Но лучше пользоваться умными указателями, там это всё делается без нужды следить за этим.

[prometian]

@VoidEx , еще вопрос возник. Про умные указатели почитал, в целом к ним нужно стремиться, шикарно закрывают эти косяки.
Вот глядите,
void * data = malloc(buffer*sizeof(int));
void * start = data;

/*манипуляции с значениями по адресу, data в середине буфера или на последнем элементе*/

// вариант 1:
free(start);
std::cout << *(int*)data << std::endl; // мусор, видимо генерируемый отладчиком
std::cout << *(int*)start << std::endl; // мусор

// вариант 2:
free(data);
std::cout << data << " value: " << *(int*)data <

[Александр Ручкин]

Комментарий, видимо, обрезан, вариант 2 не до конца.

[prometian]

И правда срезало... Суть
std::cout << data << std::endl; // ошибка
std::cout << start << std::ednl; // ошибка
Почему если мы очищаем data и он находится в середине то получаем ошибку, ведь UB там в обоих вариантах? Или это уже специфика malloc?

[Александр Ручкин]

В каком смысле "ошибка"? Почему она два раза? У вас падает или выводит мусор? И вы же выводите указатели, а не то, что лежит по их адресам.

[prometian]

В варианте один - выводит мусор, в варианте два падает. Код выполняется не одновременно, т.е. это разные программы.
Вот, в первом варианте если я вывожу указатель и значения - падения нет
А во втором - падает даже если я просто указатель вывожу.

[Александр Ручкин]

Потому что free(data) - это тоже UB, free надо звать только к тому указателю, что вернул malloc. Вы передаёте ему иной указатель, и портите таким образом кучу. Что конкретно и каким именно образом там ломается - я не знаю, гадать не буду, но суть именно в этом.

[prometian]

Понял. У меня была мысль что malloc записывает куда-то адрес начала и длину блока, но все-равно было любопытно сработает ли очистка блока, даже если ткнули в его середину. Спасибо

Answer 2

[GavriKos]

Проверка происходит грубо говоря на уровне ОС. Например, XP и win7 в случае записи за предел массива реагируют по разному - семерка чаще всего крешит приложение, семерка - отработает.

Вообще проверка а указывает ли указатель куда надо всегда на совести программиста. Причем может вполне валидным быть наращивание указателя за пределы первого массива - например если вы гарантируете что за первым массивом сразу идет второй массив.

Answer 3

[AxisPod]

А почему должна быть проверка? Может стоит почитать книги для начала. C/C++ это не те языки, где можно изучать методом научного тыка. В C/C++ нет контроля выхода за границы, если хотите, берите Java, C# и т.д.

Comments

[prometian]

А представьте что материал книг дается сложно, а общение, к примеру с @VoidEx , дало куда больше. В книге не задашь вопрос и если вылезла ошибка, то приходится вот так лезть в инет и получать комменты вида: "Может стоит почитать книги...". Кстати, Вы не предложили ни одной (хотя бы с фразой - в это шикарно описано, учился сам и все понял).
До кучи, большинство примеров из книг уже содержат работу с указателями, но она всегда рассматривается позднее, в итоге не имея преподавателя/научрука можно огрести не хилую кашицу, упорядочить которую очень не просто.

[AxisPod]

И в какой это книге не написано, что в C/C++ нет проверки за выходы границы массивов? А если действительно не написано, то значит вы неудачно выбрали материал для изучения. Ну а то что книги по C/C++ даются сложно, всё логично, это не простые языки. За неделю их не выучить, и даже за месяцы, они изучаются годами.

[prometian]

Здесь не совсем предел массива был, а чтение и попытка модификации памяти за областью массива, в другой ветке комментариев мне доступно объяснили что не так.
Материал может и правда был неудачно выбран, но отвергая - предлагайте.