В стандартной библиотеке C, опять же, по причине её универсальности и простоты, нет реализаций таких нетривиальных структур данных. Тут придётся либо положиться на внешние библиотеки (или мини-библиотеки из двух файлов: исходного и заголовочного), либо предоставлять свою реализацию.
Например, есть uthash.
Возможно, помещение списка точек останова в более эффективную для проверки наличия в ней определённого адреса позволит ускорить обработку инструкций (O(n) -> O(logn)). Например, для этого можно использовать set или unordered_set из стандартной библиотеки c++.
Пока что она всё еще очень падучая (BSOD может выдать на любой чих) и поддерживает очень мало железа (а ноутбуки — это как раз засилье кастомного оборудывания и проприетарных драйверов под него).
Ну, сдесь работают выразительные средства языка (синекдоха). Если вдуматься, то «Я съел три тарелки супа» или «Весь дом лёг спать» тоже звучит не правильно. Язык зачастую стремится к упрощению. Результат можно видеть.
Скорее всего проблема в том, что у c# нативные строки (ну и char тоже) — юникодовые (UCS-2). Поэтому карт-ридеру это и не нравится. Но я-бы для начала попробовал пообщатся с ним через какой-нибудь терминал для COM портов. И мучиться не надо, колдуя над строками, и сразу видно что отвечает…
Создать подобные папки/файлы невозможно из-за особенностей подсистемы WIN32, где эти имена зарезервированы для устройств ввода-вывода.
Far же, насколько мне известно, использует API ядра windows для рвботы с файлами, поэтому плевать эму с высокой башни на эти особенности. Как-то так.
Да, идея хороша, но… Воплотить её в жизнь будет трудно, ведь у нас есть множество сред разработки, а для каждой такое не напишешь. А кто-то вообще любитель всё это в текстовом редакторе пилить, а компилировать из консоли. Поэтому… можно но сложно.
Это не эмулятор — а подсистема. Такая же как win32. Скорее всего все вызовы там переводятся на ntdll.dll, как и в win32 api. По сути это просто еще одна оболочка над функциями ядра. Так что это не совсем эмулятор. Только чуть-чуть.
Спасибо что объяснили, но по-моему это не очень опасно. Нет вот переполнение буфера, тут всё понятно, а тут? Каков вообще шанс, что по освобождённому адресу будет другой объект? Какая-то это не опасная уязвимость. По-моему это просто баг, вызывающий падение (в большинстве случаев).
Либо я чего-то не понимаю, но всё-таки, чем опасны use-after-free уязвимости? По-моему использование освобождённой памяти вызовет падение флеша. Так почему же это уязвимость?
А вы точно уверены, что ваш код всё еще портативен и универсален?)
Например, есть uthash.
Когда нужно — расскомментируете строку с #define, а когда не нужно — комментируете.
Far же, насколько мне известно, использует API ядра windows для рвботы с файлами, поэтому плевать эму с высокой башни на эти особенности. Как-то так.