Что будет если выйти за пределы массива повредить данные а потом восстановить?

Мне интересно каковы будут последствия как с динамической памятью так и со статической. Рассматриваются варианты если 2 программы полезут в одно адресное пространство, возможно ли это в моём случае я не знаю, поэтому спрашиваю.
1.Пример со стат. памятью. Есть массивchar mas[100] у меня возникает спорная ситуация и мне приходится записать информацию в 100-103 байты. Я конечно понимаю что выхожу за пределы массива, поэтому я заранее сохраняю информацию которая хранилась в диапазоне 100-103 и позже записываю её назад.
Рассматриваемые варианты.
а) Если доступ к статической памяти синхронный/последовательный ничего не произойдёт. Процессор будет ждать пока освободится первый поток, а в 1ом потоке есть задача записать байты назад и лишь затем полезет в область данных 100-103.
б) В конце каждого массива лежит байтслово, т.е. дополнительные 4 байта или sizeof(char*)(каков там будет размер зависит от того сколько памяти занимает указатель), в этом случае у нас есть дополнительные байты которые будут отделять 2ой поток от 1го, 2ой поток в этом случае возьмёт своё начало на 104 байте. Но опять же учитывая то что Майкрософт использует байтслова, повреждение байтслова может вызвать ошибку и 2ой поток может неправильно взять память под себя. Опять же доказательств всему этому нет. В целом по этому пункту считаю что ничего не произойдёт.
в) Возможно если мы повредим байтслово, которое находится в диапазоне 100-103, то может возникнуть утечка памяти на 4 байта или sizeof(char*). Далее когда поток 1 завершится байтслово будет записано назад и в конечном итоге память восстановится. По этому пункту считаю что ничего не произойдёт.
г) Вариант с описателем. Т.к. статические массивы имеют описатель то поток 2 тупо захватит новый участок памяти на 104 байте, его вообще не будет интересовать что происходит в диапазоне 100-103. По этому пункту считаю что ничего не произойдёт.
д) Если функции имеют разный стэк а это так, потому что они разные но используют одну память, в этом случае поток 2 не достанет до потока 1, т.е. снижается вероятность что они пересекутся. В этом случае ничего не произойдёт.
е) Поток 2 будет обрезать поток 1ин если тот выходит за пределы массива. Звучит не очень надёжно.
2. По динамической памяти примерно те же варианты, с единственной оговоркой- есть возможность управлять критическими секциями, в этом случае можно защитить критические байты или проигнорировать происходящее.

0

Сообщение от Nexi99 Если вы знаете что за границами массива за него можно спокойно выходить.

Хм, допустим, чем Вам поможет такое знание ?
Что практически даст вам выходить за пределы массива ?
Зачем все это ?

Если хотите чего то добиться, играть нужно по правилам.
Если хотите владеть хорошо ЯП, возможностями уже готовых конструкций - их нужно знать. И опять же - играть по их правилам.

Все эти непонятные заморочки, в результате получите целую кучу ненужной работы.

Сообщение от Nexi99 если речь идёт о статическом массиве

это одна из причин зачем таким массивам делают разного рода обертки std::array, например
что бы избавить себя от передачи таких массивов, от привязки к ним размера и т.д.

Я честно ничего не понял.

0

Сообщение от OpXiv Вот, азы про всё и вся. Включая что будет если записать то, куда записывать не надо. Например за границу массива. https://ravesli.com/urok-75-massivy-chast-2/

Там кстати умная вещь написана. За границей массива может лежать данные переменной, которая будет использована в текущий момент.

А ТС просто возьмёт и перезапишет данные,и данные переменной уже не будут указывать на нужные данные.

0

Сообщение от OpXiv Вот, азы про всё и вся. Включая что будет если записать то, куда записывать не надо. Например за границу массива.

Там написано даже меньше чем предположил я. Да и к тому же как устроена память и когда и в какой момент используется часть неизвестно, может прокатить а может и нет. До сих пор никто не знает даже как получить размер статического массива и его приходится постоянно передавать.

Добавлено через 6 минут
В целом пользователь считает что может накрыться другая программа, видимо очень опасно.

0

Сообщение от Nexi99 может прокатить а может и нет

Пользователей твоей программы скорее 100% может не быть.

0

Сообщение от OpXiv Пользователей твоей программы скорее 100% может не быть.

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

0

Сообщение от Nexi99 А вот работа с динамической памятью куда обширнее

Это лишь тебе кажется. Просто ты ленишься выделять когда нужно, и освобождать когда не нужно.

А вообще тебе уже порекомендовали использовать std::array

0

Сообщение от OpXiv Это лишь тебе кажется. Просто ты ленишься выделять когда нужно, и освобождать когда не нужно.

Это не шуточка с которой можно полениться.

0

Nexi99, если Вы хотите обрабатывать массив бОльшими блоками "с запасом", то и определяйте массив с запасом, например, кратным 16 байт.
Единственное, что программа имеет право делать за пределами char mas[100], это &mas[100]. Современные стандарты требуют, чтобы при такой операции фактически не происходило обращение к mas[100] ( *(mas+100) ).

То, что фактически происходит при доступе потоков к соседним в памяти объектам - забота разработчиков ЭВМ, ОС и компилятора. Они должны позаботится о том, чтобы корректно написанная программа работала корректно.

0

Сообщение от Nexi99 Вы бросаетесь в крайности. Почему все сразу спихивают на UB. Если вы знаете что за границами массива за него можно спокойно выходить.

Выход за пределы диапазона - это UB согласно правилам языка.
Вот если вы вдруг не поняли - так написано в правилах языка.
При чем тут какие то крайности?

На практике такой выход за пределы диапазона в лучшем случае приведет к крашу.
На случай, если вы друг не поняли, я ещё раз подчеркну мысль:
Гибель процесса - это лучшее, что вас ждет.
Возможная альтернатива намного хуже.
В худшем случае, можно незаметно испортить память, и потом долго-долго удивляться странным глюкам.
Диагностировать и искать потом такие баги можно будет очень долго и сложно.

Специально для вас: совершенно не важно, что именно находится за границами массива.
Сам факт выхода за границы массива уже делает всё дальнейшее поведение программы не определенным.

Вот это - просто запредельно идиотское решение:

Сообщение от Nexi99 Есть массивchar mas[100] у меня возникает спорная ситуация и мне приходится записать информацию в 100-103 байты. Я конечно понимаю что выхожу за пределы массива, поэтому я заранее сохраняю информацию которая хранилась в диапазоне 100-103 и позже записываю её назад.

Это называется: создать себе проблемы на ровном месте, а потом героически их преодолевать.
Что мешает изначально создать те же самые 103 элемента? Или 200 элементов? Или сколько вам там ещё нужно с вашими "спорными ситуациями"
Получите ту же самую возможность дописать что либо в хвост массива, но без вот этих приседаний с вылетом за диапазон массива.

Вот зачем вы сами себе на ровном месте без какой либо причины усложняете жизнь?

Ваш код содержит просто ужасное по своей сути UB.
Сбой может произойти в любой момент в зависимости от фазы луны, или левой пятки компилятора.

0

Nexi99, короче тебе хотят тут сказать, что в чужую память лазить нельзя. но если тебе вдруг приспичило, то нужно много всего изучить, в основном как работает операционная система. за один день, даже за один год это изучить не получиться. и это уже выходит за рамки программирование на C++ и начинается хакерство, потому что придется обходить защиту операционной системы "защиту памяти процесса".

0

Сообщение от eva2326 Сбой может произойти в любой момент в зависимости от фазы луны

Идея была в том что эта память будет восстановлена причём сразу же. Первый шаг портим 2ой сразу же восстанавливаем, если память автоматически блокируется в этот момент то это можно спокойно делать, а если не блокируется то может другое ПО хватануть не те расчёты и крах. В принципе я так делал проблем не возникало никогда но т.к. нет информации как это работает то может лязнуть.

Добавлено через 59 секунд
Знать бы точно блокируется или нет какой туда доступ синхронный или свободный насколько риск силён

Добавлено через 1 минуту
В динамической памяти можно создать критическую секцию заблокировать участок и 2ой поток туда не залезет

0

Сообщение от Nexi99 Знать бы точно блокируется или нет какой туда доступ синхронный или свободный насколько риск силён

Ты бы почитал какие-нибудь книжки для начала. Хотя бы того же Рихтера.

0

Сообщение от oleg-m1973 Ты бы почитал какие-нибудь книжки для начала. Хотя бы того же Рихтера.

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

Добавлено через 1 минуту
Даже если стэк у другой функции будет дальше то уже этот участок можно трогать.

Добавлено через 2 минуты
Вот пример
Используется общий объём памяти который взят на основании 2ой функции у первой 8 байт памяти в запасе.

0

Сообщение от Nexi99 Идея была в том что эта память будет восстановлена причём сразу же.

При UB компилятор имеет право сказать "так не бывает" и вообще выкинуть проблемный код.
А при отсутствии синхронизации имеет право отложить шаг "сразу же восстанавливаем" до морковкина заговенья. Компилятор должен сохранять лишь наблюдаемое поведение программы, к которому запись данных в память обычно не относится. А существование других потоков между точками синхронизации не учитывается.

0

Сообщение от Nexi99 Идея была в том что эта память будет восстановлена причём сразу же.

Для чего? Неужели сложно сделать нормально??? Что ты вообще делаешь????


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

0

Сообщение от Renji А при отсутствии синхронизации имеет право отложить шаг "сразу же восстанавливаем"

Ну да даже при присутствии между обращениями 2ой поток может влезть в ту секцию где данные повреждены и программа использующая их может лязнуть.

Сообщение от OpXiv Если ты хочешь место под буфер

так и сделал, но копирование буфера это время а так подтасовал их туда сюда в 2 действия и всё. Хочу сэкономить но скупой платит дважды, думаю посоветуюсь с пользователями может знают что.

0

Сообщение от Nexi99 посоветуюсь с пользователями может знают что.

Может и знают, только вопросы надо грамотно задавать. Например - какие функции ты вызываешь, какие инструменты используешь. Что пишешь в буфер.

0

Сообщение от OpXiv Может и знают, только вопросы надо грамотно задавать. Например - какие функции ты вызываешь, какие инструменты используешь. Что пишешь в буфер.

Можете по этому Сколько времени действует критическая секция? вопросу что-нить подсказать? Только пишите по ссылке а не здесь

0

Сообщение от politoto Единственное, что программа имеет право делать за пределами char mas[100], это &mas[100].

&mas[100] эквивалентен &*(mas + 100) и в C++, в отличие от C, соседние &* не отменяют вычисление друг друга, так что *(mas + 100) вычисляется.
Оператор * в C++ требует указателя на объект, а mas + 100 на объект не указывает.

0

Сообщение от politoto Единственное, что программа имеет право делать за пределами char mas[100], это &mas[100]

Сообщение от argcargv &mas[100] эквивалентен &*(mas + 100) и в C++, в отличие от C, соседние &* не отменяют вычисление друг друга, так что *(mas + 100) вычисляется. Оператор * в C++ требует указателя на объект, а mas + 100 на объект не указывает.

Если я всё правильно поняла, то нельзя вообще даже просто создать указатель на объект за пределами диапазона.
(За исключением end. Об этом ниже)
То есть, вот такой код уже содержит UB:

В примере выше просто создаётся указатель.
Но при этом через него ничего не делается: ни чтения, ни записи.
И тем не менее, код уже содержит UB.

Для поддержки работы итераторов допускается указатель end, который указывает за последний элемент массива.
Но и только лишь. Его нельзя будет ещё раз инкрементировать:

http://eel.is/c++draft/expr.add#4.2

0