Вот самый утрированный пример: Код (Text): public static class C { public static int SumItUp(int[] array) { int sum = 0; foreach(var item in array) { sum += item; } return sum; } public static int SumItUp2(int[] array) { int sum = 0; for(var i = 0; i < array.Length; i++) { sum += array[i]; } return sum; } public static int SumItUp_Exception(int[] array) { int sum = 0; for(var i = 0; i < array.Length + 10; i++) { sum += array[i]; } return sum; } } Код (Text): C.SumItUp(Int32[]) L0000: push ebp L0001: mov ebp, esp L0003: push edi L0004: push esi L0005: xor eax, eax L0007: xor edx, edx L0009: mov esi, [ecx+4] L000c: test esi, esi L000e: jle short L001b L0010: mov edi, [ecx+edx*4+8] L0014: add eax, edi L0016: inc edx L0017: cmp esi, edx L0019: jg short L0010 L001b: pop esi L001c: pop edi L001d: pop ebp L001e: ret C.SumItUp2(Int32[]) L0000: push ebp L0001: mov ebp, esp L0003: push esi L0004: xor eax, eax L0006: xor edx, edx L0008: mov esi, [ecx+4] L000b: test esi, esi L000d: jle short L0018 L000f: add eax, [ecx+edx*4+8] L0013: inc edx L0014: cmp esi, edx L0016: jg short L000f L0018: pop esi L0019: pop ebp L001a: ret C.SumItUp_Exception(Int32[]) L0000: push ebp L0001: mov ebp, esp L0003: push edi L0004: push esi L0005: xor eax, eax L0007: xor edx, edx L0009: mov esi, [ecx+4] L000c: lea edi, [esi+0xa] L000f: test edi, edi L0011: jle short L0020 L0013: cmp edx, esi L0015: jae short L0024 L0017: add eax, [ecx+edx*4+8] L001b: inc edx L001c: cmp edi, edx L001e: jg short L0013 L0020: pop esi L0021: pop edi L0022: pop ebp L0023: ret L0024: call 0x0fd075d0 L0029: int3
Ога. А если он этого установить не может (вангую, если пределы индекса не заданы явно в цикле), то сделать он этого не сможет и проверка индексов будет всегда, даже если нам точно известно, что выхода за пределы никогда не произойдет. --- Сообщение объединено, 24 мар 2021 --- Если ты используешь какой-то модуль, его функционал строго определен его интерфейсом. У себя внутри пусть хоть через строку исключения бросает, но наверх они попасть не должны. А если его внутренние исключения рушат хост, то это отличная причина отключить этот плагин и удалить, оставив соответствующий отзыв во всех тиктоках. Так, глядишь, и конкуренция основанная на качестве продуктов появится. Духами сверху побрызгал и вроде не воняет, да?
Я не говорю о багах реализации, я говорю о багах архитектуры. К примеру в том же VB6 следуя концепции безопасного программирования не получится реализовать такие низкоуровневые ошибки. Все ошибки которые возможны в такой системе - Runtime Error. Ну это хорошо что это так работает. А если цикл по произвольным элементам, но элементы внутри (к примеру Random % array.Length)? Или к примеру такой код как заоптимизируется, есть массив байт - пиксели изображений и мы делаем блендинг для каждого байта по маске. Т.о. цикл у нас с шагом 4 (RGBA), а в цикле обращение идет как pix[i + 1], pix[i + 2] и т.д. Если есть возможность - покажи пожалуйста. Почему не должны? Ну мы не отвечаем за это, нам нужно сделать максимально удобно для пользователя. Как раз как я описал - удобно. Вот тут интересная статья по OllyDbg как человек производил целое исследование чтобы сохранить проект. Не понимаю тебя, если ты не согласен что это удобно - твое дело. Переубеждать тебя не буду.
В этом случае элементы могут быть не внутри, так как Random или какая-то внешняя функция может вернуть отрицательное значение. И кстати, когда мы делаем n % array.Length нужно еще удостовериться, что array.Length не равен нулю)) Если я правильно тебя понял, то: Код (Text): public static class C { public static int SumItUp(int[] array) { int sum = 0; for(var i = 0; i < array.Length - 4; i += 4) { sum += array[i]; sum += array[i + 1]; sum += array[i + 2]; sum += array[i + 3]; } return sum; } } Код (Text): C.SumItUp(Int32[]) L0000: push ebp L0001: mov ebp, esp L0003: push esi L0004: xor eax, eax L0006: xor edx, edx L0008: mov esi, [ecx+4] L000b: add esi, 0xfffffffc L000e: test esi, esi L0010: jle short L0029 L0012: add eax, [ecx+edx*4+8] L0016: add eax, [ecx+edx*4+0xc] L001a: add eax, [ecx+edx*4+0x10] L001e: add eax, [ecx+edx*4+0x14] L0022: add edx, 4 L0025: cmp esi, edx L0027: jg short L0012 L0029: pop esi L002a: pop ebp L002b: ret Наши спецовые цешники никому ничего не должны, они должны клепать наколенный код, который никто кроме них не будет использовать, поэтому они не в курсе, как вообще делается нормальный софт. Довольно забавно представить себе ситуацию, выпустил ты софт и заюзал какую-то библиотеку, которая периодически исключение вываливает. К тебе клиент приходит и говорит, фикси мол давай, а ты ему, это не мои проблемы, это эксепшн в библиотеке, иди мол сам на гитхаб этой библиотеки и репорти им баг, если пофиксят, тогда и поговорим. Или отвалился какой-то внешний нативный плагин и все, процесс упал, давай до свидания, вся несохраненная работа пользователя.
Неплохо. Спасибо, не знал об этой фиче. Ну если она unsigned к примеру. Да это понятно, я написал чтобы понятна была суть вопроса.
Какие-то слишком утрированные примеры. Ты давай такое, где избыточная проверка индексов окажет существенное влияние на производительность, а не простой массив скаляров. Типа, как в том примере на расте, что недавно рассматривали, когда трехстрочный сорец по перебору элементов контейнера в 3к машинных инструкций компилился (или сколько там было, не помню? но в пост из-за лимитов не влезло).
Есть еще одна забавная фича в этом ключе, но мне еще не довелось ее заюзать: https://habr.com/ru/post/435840/ Ну тут у нас есть семантическая проблема в том, что длина чего либо в дотнете является по неведомой мне причине знаковой величиной, когда мы переведем ее из беззнаковой и опустим проверку на переполнения, то она может быть отрицательной. Тут вряд ли получится обойтись без проверок: (1) на то, что array.Length не нулевой (из-за модуля) и (2) проверки индекса. Ну как минимум мне пока не приходит в голову такой способ. Можно канеш перейти в реалм ансейф кода (ключевое слово unsafe) и херачить указателями, но это уже будет читерство, хотя и рантайм вполне позволяет это делать.
Вот меня тоже интересует этот момент. Может, это какая-то мировоззренческая проблема у авторов .net? Релятивизм головного мозга?..
Да, это тупо, даже в сишечке/плюсах size_t вроде беззнаковый на всех архитектурах, если мне память не изменяет. Могу предположить, что для шарпов uint существует только на уровне компилятора, а сама виртуальная машина CLR обрабатывает только знаковые целые (вся семантика беззнаковых целых - абстракция над знаковыми). Поэтому вводить в стандарт практику подсчета длин чего-либо в беззнаковых интах мелкомягкие засцали в первых версиях, а потом, из-за их фанатичной любви к обратной совместимости, что-то менять было поздно. Но это только предположение.
Thetrik, > Я не говорю о багах реализации, я говорю о багах архитектуры. Моё скромное мнение - вы не то обсуждаете. Ошибки почти всегда алгоритмические, а не на компиляторном уровне. Стек компилер не даст переполнить, если конечно не допущена тупая ошибка в скрипте. Если скрипт описан без ошибок, то всё равно будет ошибка на уровне алгоритма. Так очень давно пробивался авер асинхронной атакой. При этом в сурках ошибок небыло, качественная сборка нэйтив - она в алгоритмах синхронизаций была. Чем проще яп(интерфейс), тем тупее кодер и больше он ошибок насыпет, сделав код уязвимым(не понимая например отображение скрипта на выхлоп компилера в простейшем случае не говоря уже про динамику). Это правило работало работает и будет работать всегда.
Microedition, Был бы семпл, ошибка всегда найдётся. Выше я говорил, ты узко мыслишь - есть разница между сборкой компилером/интерпр и алгоритмическими ошибками. Ты про пробив и защиту ничего не знаешь, но пойми суть - есть потоки данных, те их источник, затем у этих данных есть наследование. Утеря какой то порции данных - это уязвимость, это и есть метод их обнаружения. "Dereference Under the Influence" - гугли, кури матчасть это большая фундаментальная публикация по защите.
Это как раз не удивительно. Вот если бы на канале эмбеддед цешников появился видос о том, что они начали использовать аду или раст...
rmn, Заметь что не смотря на его весьма длительное пребывание в теме" он не способен даже использовать отладчик, тут рядом тема. Свой же высер он не может отладить, лишь обсудить не дальше сборки
Самое забавное, что я это слышу только от двух человек, которые ну вот совсем не добились ничего. Ну кроме срачей на форумах.
Я мб неправильно выражаюсь, но я имею в виду (и думаю что и рел тоже) что в таких ЯП не может быть таких низкоуровневых ошибок о которых я выше написал типа UAF/BUFOVERFLOW и т.п. Если такие и есть то они обусловлены не багами архитектуры, а багами реализации. Т.е. изменив реализацию - и баг пропадет. К примеру мне на память приходит уязвимость в VBS которая позволяла использовать уязвимость UAF когда в Class_Terminate счетчик ссылок объекта увеличиваешь. Этот баг быстро закрыли, ни один скрипт который до этого работал в нормальном режиме не пришлось переписывать. Т.е. изначально была кривая реализация самого компилятора. Используя концепцию безопасного программирования такие ошибки в принципе невозможны. Используя сырые указатели в С мы запросто можем "выстрелить себе в ногу" неинициализировав его, либо что-то не туда записав. Вместо указателей в том же ВБ используются ссылки которые полностью безопасны, ссылка никогда не может ссылаться на какой-то мусор и т.п. Там есть проблема циклических ссылок, но это проблема самого COM, но и тут самое худшее что мы можем получить это утечку памяти, но не уязвимость. Проблема циклических ссылок решена в дотнете. Вместо вызова той же функции по указателю используется вызов метода интерфейса что тоже безопасно.
Ну есть мои статьи и тут и на хссе, а вот от тебя и твоего дружка цэшника ничего толкового не было никогда. Какая то шняга, которую ты называешь статьями бесполезна, так как во-первых очень паршиво написана, во-вторых никто ее так и не применил и не применит. За мои статьи люди писали мне благодарности и тут и на хссе, они занимали призовые места на конкурсах. А у тебя кроме твоей фантазии и аверских задач нет ничего, вообще ничего не существует. Так что ты бы лучше за собой следил, а не за мной. А то мотивации у него нет, бедный несчастный, ты просто не на что не способен и пытаешься какими то эфимерными величинами прикрываться. --- Сообщение объединено, 24 мар 2021 --- Все нуби, разница в том, что эти нуби смогли то, чего ты не смог: хоть что-то из себя представлять в этой жизни. --- Сообщение объединено, 24 мар 2021 --- Это проблема любой системы, которая использует счетчик ссылок, в дотнете это разруливает GC в динамике, но в статике, чтобы компилятор мог это разруливать, приходится загонять себя в рамки того же борроу чекера из Растового компилятора.
Rel, Если тебя словили то будь честным признай, незачем пытаться извернуться как рыба на сковороде, бессмысленно.
Rel, А с чего ты решил что я два дня решал, там пол часа было. Я как бы работаю не по коденгу и было сказано в первый день что я пьяный компилер открывать не буду, тк это бессмысленный напряг. На второй вечер я ничего не собирал, а тупо старый билд нашёл, который решил штатную задачу даже без пересборки и я выложил сурки. Не искажай факты, тут же не ты один и все помнят как было по факту. > а твой визор (твой главный проект, твоя гордость и тд) ни на что не годен. Какие тебе визоры если ты отладчиком нуби семпл открыть не можешь)
