-
- а этот фокус можно и на контроллере исполнить. Nikolay801_(136 знак., 01.10.2020 10:10, картинка)
- А писать он будет в array[countof(array) + 1234]... - fk0(02.10.2020 10:52)
- Статический анализ показывает все спорные места. А потом ручками. - VLLV(30.09.2020 23:44)
- Учитывая поступившие предложения получается, что сам буфер можно
оставить типа int, а указатель сделать отдельным типом CPtr. В
версии для м/к это будет typedef in t*CPtr; Для этого типа надо
будет написать: AlexBi(534 знак., 30.09.2020 16:22)
- Нет никакого смысла в указателях вообще. Они нужны для специальных задач, а не для пользовательского кода. В остальных случаях нужны скорей итераторы. И даже пара итераторов, указывающих на границы диапазона, который можно только сужать, но не расширять. Тогда ошибку в принципе допустить невозможно. И даже если в контроллер затянуть std::span, то на производительности это практически не скажется. Реализацию std::span (отсутствующего в древнем тулчейне для мк) можно поискать fk0(60 знак., 02.10.2020 11:00, ссылка)
- Если к указателю прибавить или вычесть целое, результат должен попадать в исходный массив или указывать на один элемент дальше последнего элемента. Иначе undefined behavior. - SciFi(30.09.2020 16:25)
- За границы буфера? Address Sanitizer (встроен прямо в Clang или
GCC!), Valgrind (плохо или не работает для статически
распределённой памяти). Если C++, то можно сделать смарт-указатель,
у которого переопределены (только на ПК) operator* и operator[]
так, что имею проверку диапазона... Разумеется внутри он должен
хранить не только указатель, но и начало/конец диапазона.
Рекомендую начать с Address Sanitizer. Кстати он проигрывает
Valgrind'у в одном: последний умеет fk0(204 знак., 30.09.2020 12:47)
- У меня MS, от которого отказаться довольно сложно, поэтому Address
Sanitizer не знаю как применить. Присматриваюсь к самодельному
смарт-указателю (написал выше). - AlexBi(30.09.2020 16:22)
- Для M$ есть во-первых Dr. Memory. Но он как и Valgrind не будет работать со статически распределённой памятью. Поэтому от статического распределения лучше вообще отказаться. Если malloc якобы не нужен и опасен -- то можно распределить всю память в момент старта программы, а потом не трогать. Но во всяком случае для динамической памяти тот же Dr. Memory успешно начинает работать. - fk0(02.10.2020 10:50, ссылка)
- Надо не "границы массивов" проверять, а сразу писать код так, чтоб минимизировать вероятность ошибки. В частности, отказаться по возможности от сырых указателей, и указателей вообще. Например, позаимствовать span из C++20. Для строк -- string_view из C++17. Во всех случаях подразумевается некий класс, который оперирует последовательностью доступной через пару итераторов, но не владеет им. Владеет им кто-то другой. fk0(133 знак., 02.10.2020 09:52)
- Так в студии есть аналогичная опция. - Kabdim(30.09.2020 17:51, ссылка)
- Она нихрена не аналогичная. Она аналогична другой -- -fstack-protector. Речь же про данные размещённые статически или в куче, а не на стеке. - fk0(02.10.2020 10:47)
- Оно там по умолчанию включено, однако от выхода за границы
статического массива не защитило. Столкнувшись с этим фактом я
задумался о самодельной защите. AlexBi(143 знак., 30.09.2020 18:16)
- Если есть возможность для дектопа переделать на std::array , то можно воспользоваться вот штукой. Или самописной вроде такой. Kabdim(9 знак., 01.10.2020 13:54, ссылка, ссылка)
- std::array.at() бросает исключение при выходе за границы массива, этого достаточно, чтобы обнаружить проблему у синтетического порта на ПК. Можно использовать и в МК, только придется как-то отлавливать исключение. - evgeniy1294(30.09.2020 18:23)
- У меня MS, от которого отказаться довольно сложно, поэтому Address
Sanitizer не знаю как применить. Присматриваюсь к самодельному
смарт-указателю (написал выше). - AlexBi(30.09.2020 16:22)
- в лабвиндовс когда отлаживаешь в debug режиме, он сам молча
добавляет код проверки индексов массива. ашчушчэние, что пишешь на
шарпе, а не на сях. - Mahagam(30.09.2020 12:35)
- У меня в арсенале только С++. А с указателями эта проверка тоже
работает, или только при обращении по индексу? - AlexBi(30.09.2020 12:45)
- вот не вспомню. - Mahagam(30.09.2020 12:52)
- У меня в арсенале только С++. А с указателями эта проверка тоже
работает, или только при обращении по индексу? - AlexBi(30.09.2020 12:45)
- Вот так? >>> - SciFi(30.09.2020 12:22, ссылка)
- Такое я представляю, в моем случае даже шаблоны не понадобятся,
т.к. тип и размер известны заранее. Не представляю как сделать
указатели, что бы вся арифметика и прочая работа с указателями
сохранилась, но при этом и выход за границы проверялся. И что бы в
тексте программы были обычные buf[123] и *prt, и что бы так
(ptr<&buf[5]) работало. Я не слишком много хочу? - AlexBi(30.09.2020 12:41)
- Ну так для указателей тоже можно сделать класс, который всё будет
делать как надо, нет? - SciFi(30.09.2020 12:44)
- Можно. Только хочется сохранить запись foo(CTyp *ptr), а не
переходить к foo(CTypPtr ptr), что бы простым typedef-ом все
возвращалось обратно в int. Да и привычнее видеть в тексте
указатель как *ptr. - AlexBi(30.09.2020 12:54)
- Еще лучше один раз написать typedef CTyp* PTyp, а символ умножения использовать как символ умножения. Boвa(51 знак., 30.09.2020 17:12)
- Дохера работы толькo, нужно переопределить кучу операторов. Потом в месте присвоения указателя нужно задавать границы массива (а в коде для МК -- не нужно). Поэтому от сырых указателей проще вообще избавиться, просто на МК подсовывать упрощённую реализацию, которая границ массива не запоминает и ничего не проверяет. - fk0(30.09.2020 12:49)
- Можно. Только хочется сохранить запись foo(CTyp *ptr), а не
переходить к foo(CTypPtr ptr), что бы простым typedef-ом все
возвращалось обратно в int. Да и привычнее видеть в тексте
указатель как *ptr. - AlexBi(30.09.2020 12:54)
- Ну так для указателей тоже можно сделать класс, который всё будет
делать как надо, нет? - SciFi(30.09.2020 12:44)
- Такое я представляю, в моем случае даже шаблоны не понадобятся,
т.к. тип и размер известны заранее. Не представляю как сделать
указатели, что бы вся арифметика и прочая работа с указателями
сохранилась, но при этом и выход за границы проверялся. И что бы в
тексте программы были обычные buf[123] и *prt, и что бы так
(ptr<&buf[5]) работало. Я не слишком много хочу? - AlexBi(30.09.2020 12:41)
- а этот фокус можно и на контроллере исполнить. Nikolay801_(136 знак., 01.10.2020 10:10, картинка)