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

Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало.

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

Я занимаюсь изучением синтаксиса языков программирования и пытаюсь отделить фундаментальные закономерности от исторических случайностей. Одна из таких случайностей - почти повсеместное использование терминов выражение (expression) и инструкция (statement) при описании и классификации синтаксиса языков программирования.

Интуитивно кажется, что 2 + 2 и if (x) { foo(); } - это совершенно разные сущности, но при более глубоком анализе оказывается, что подобное разделение искусственное и возникло из-за архитектурных особенностей вычислительных машин почти полвека назад и с тех пор просто «переходит» из языка в язык.

Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы:

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

А раз текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов, то выходит, что:

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

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

Модель памяти представляет из себя спецификацию допустимого поведения многопоточных программ, работающих с разделяемой памятью (shared memory) [1]. Наиболее примитивной моделью является последовательная согласованность (sequential consistency), где все инструкции из всех потоков образуют общий порядок (или, по крайней мере, его видимость), согласованный с порядком выполнения программы в каждом потоке [2].

Одной из наиболее важных фич C++11 является модель памяти, поддерживающая параллелизм, которая позволяет писать многопоточные программы, не полагаясь на различные расширения для конкретных целевых платформ.

Язык программирования Go (так же известный как Golang) с каждым днем все больше и больше программистов хотят на нем писать программы. Для хакеров этот язык программирования становится еще более привлекательным за счет кросс-компиляции для различных платформ - Windows, Linux, MacOS. Например, хакеры могут написать загрузчик на Go, внутри может быть ВПО, созданное с использованием более распространенного языка.

На Go также пишутся так называемые дропперы, использующиеся для декодирования, загрузки и установки ВПО. Все идет к тому, что Go, вероятно, будет еще чаще использоваться злоумышленниками. Уже появлялись и шифровальщики использующие Go для шифрования основного вредоносного модуля. Одним из самых примитивных примеров использования Go - написание кроссплатформенного ReverseShell . Отсюда и вытекает необходимость реверс-инжиниринга бинарных файлов написанных на язке Go.

Некоторые особенности языка программирования Go усложняют задачу реверс-инженерам при исследовании бинарных файлов Go. Инструменты обратного проектирования (например, дизассемблеры) могут отлично справляться с анализом двоичных файлов, написанных на более популярных языках (например, C, C++, .NET), но Go создает новые проблемы, которые делают анализ более громоздким.

Бинарные файлы Go обычно статически связаны, что означает, что все необходимые библиотеки включены в скомпилированный бинарный файл. Это приводит к большим размерам файла, что затрудняет распространение вредоносного ПО для злоумышленников. С другой стороны, некоторые продукты безопасности также имеют проблемы с обработкой больших файлов. Это означает, что большие двоичные файлы могут помочь вредоносным программам избежать обнаружения. Другое преимущество статически связанных двоичных файлов для злоумышленников заключается в том, что вредоносное ПО может работать на целевых системах без проблем с зависимостями.

Это вторая часть нашей серии о реверс-инжиниринге двоичных файлов Go с помощью Ghidra. В предыдущей статье мы обсуждали, как восстановить имена функций в удаленных файлах Go и как помочь Ghidra распознавать и определять строки в этих двоичных файлах. Мы сосредоточились на двоичных файлах ELF, лишь кратко упомянув различия между PE-файлами.

В этой статье будет обсуждаться новая тема - процесс извлечения информации о типе из двоичных файлов Go. Мы также более подробно объясним, как обращаться с файлами Windows PE. И, наконец, мы исследуем различия между различными версиями Go, включая изменения, произошедшие со времени нашей последней публикации в блоге.

Зачем это нужно

Доступ к файлам через отображение-в-память (mmap) — это способность некоторых операционных систем отобразить содержимое какого-либо файла в адресное пространство программы. Сама программа получает доступ к содержимому файла через указатели, как если бы сам файл был бы целиком загружен в оперативную память. Операционная система прозрачно загружает части файла в оперативную память, и автоматически выгружает их, когда памяти не хватает.

MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь.

Покуда разработчики по прежнему пытаются использовать mmap в новых СУБД, мы написали эту статью, чтобы предупредить остальных, что mmap это не подходящая замена привычному буферу. Далее мы обсудим основные недостатки mmap, а также покажем явные ограничения производительности, которые мы обнаружили в наших экспериментах. На основании этих находок мы поделимся рецептами, когда разработчикам СУБД следует избегать mmap для реализации файлового ввода/вывода.

Всем привет! Меня зовут Анна Васильева, я технический менеджер в K2 Cloud и люблю запускать утилиты с максимально возможным уровнем verbose.

Есть фраза, после которой расследование сбоя обычно становится интереснее: «Я ничего не менял». Через несколько часов выясняется, что изменения всё-таки были. Инженер распаковал архив, добавил сетевой интерфейс, обновил библиотеку или перенёс виртуальную машину на другой хост. Действие казалось безобидным, а его последствия проявились в неожиданном месте.

На митапе «Инженеры перебрали / кейсы по Linux» мы взяли семь реальных случаев и разобрали их вместе с экспертами:

Для написания эффективных и корректных многопоточных приложений очень важно знать какие существуют механизмы синхронизации памяти между потоками исполнения, какие гарантии предоставляют элементы многопоточного программирования, такие как мьютекс, join потока и другие. Особенно это касается модели памяти C++, которая была создана сложной таковой, чтобы обеспечивать оптимальный многопоточный код под множество архитектур процессоров. Кстати, язык программирования Rust, будучи построенным на LLVM, использует модель памяти такую же, как в C++. Поэтому материал в этой статье будет полезен программистам на обоих языках. Но все примеры будут на языке C++. Я буду рассказывать про std::atomic, std::memory_order и на каких трех слонах стоят атомики.

Всем привет! Давно хотел собрать пост по структурам данным, которые есть в C++ и кратенько описать преимущество каждой из них.
В первой итерации статьи начнем с тех, что есть в стандартной библиотеке STL.

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

Стандартная библиотека C++ (STL) предоставляет широкий набор структур данных, каждая из них решает определённый класс задач: от линейного хранения элементов до ассоциативных структур с поиском по ключу.
В этой статье мы кратко рассмотрим основные контейнеры, их внутреннюю организацию и типичные сценарии применения.

Определение

Инкапсуляция это набор инструментов для управления доступом к данным или методам которые управляют этими данными. С детальным определением термина “инкапсуляция” можно ознакомиться в моей предыдущей публикации на Хабре по этой ссылке. Эта статья сфокусирована на примерах инкапсуляции в Си++ и Си.

Инкапсуляция в Си++

По умолчанию, в классе (class) данные и методы приватные (private); они могут быть прочитаны и изменены только классом к которому принадлежат. Уровень доступа может быть изменен при помощи соответствующих ключевых слов которые предоставляет Си++.

В Си++ доступно несколько спецификаторов, и они изменяют доступ к данным следующим образом:

Определение

Значение термина «инкапсуляция» расплывчато и отличается от источника к источнику. Принято считать, что инкапсуляция — один из основополагающих принципов ООП, хотя некоторые научные статьи вовсе упускают инкапсуляцию из списка. К примеру, Джон Митчелл в книге «Концепты в языках программирования» при перечислении основных концептов в ООП упоминает только абстракцию — термин который принято считать близким к инкапсуляции по значению, но все-же более обширным и высокоуровневым. С другой стороны, Роберт Мартин в его книге «Чистая архитектура» явно говорит о том, что инкапсуляция, наследование и полиморфизм считается фундаментом ООП.

Разнообразие определений, данных термину «инкапсуляция», сложно привести к общему знаменателю. В целом можно выделить два подхода к значению этого термина. Инкапсуляция может быть рассмотрена как:

• связь данных с методами которые этими данными управляют;
• набор инструментов для управления доступом к данным или методам которые управляют этими данными.

Инкапсуляция как связь

В этой статье наследование описано на трех уровнях: beginner, intermediate и advanced. Expert нет. И ни слова про SOLID. Честно.

Beginner

Что такое наследование?

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

Класс, который наследует данные, называется подклассом (subclass), производным классом (derived class) или дочерним классом (child). Класс, от которого наследуются данные или методы, называется суперклассом (super class), базовым классом (base class) или родительским классом (parent). Термины “родительский” и “дочерний” чрезвычайно полезны для понимания наследования. Как ребенок получает характеристики своих родителей, производный класс получает методы и переменные базового класса.

Наследование полезно, поскольку оно позволяет структурировать и повторно использовать код, что, в свою очередь,

Одна из самых эзотерических тем в программировании и computer science это продолжения (continuations), ограниченные продолжения (delimited continuations) и continuation-passing style. Я попытаюсь раскрыть эту тему понятным для обычного программиста языком. Предполагается, что обычный программист знаком с понятиями функции/подпрограммы, фрейма вызова (stack frame), а также имеет базовое знания языка Scheme, хотя бы на уровне первых глав SICP.

Во время работы наша команда постоянно сталкивается с некоторыми особенностями языка, которые могут быть неизвестны рядовому C++ программисту. В этой статье мы расскажем о том, как работает, казалось бы, обыденная вещь – forward-декларации классов.

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

C++ сложный и интересный язык, совершенствоваться в нем можно чуть ли не всю жизнь. В какой-то момент мне захотелось изучать его следующим образом: взять какой-то аспект языка, возможно довольно узкий, и разобраться с ним максимально глубоко и подробно. Такой подход в значительной степени был стимулирован замечательными книгами Скотта Мейерса, Герба Саттера и Стефана Дьюхэрста. Когда накопилось определенное количество материалов, решил познакомить с ними Хабровчан. Так появилась эта серия, которую я назвал «C++, копаем вглубь». Серия помечена как Tutorial, но ориентирована она все-таки не на начинающих, а скорее на intermediate уровень. Первая тема — это перегрузка в C++. Тема оказалась очень обширной и получилось три статьи. Первая статья посвящена перегрузке функций и шаблонов, вторая перегрузке операторов и третья перегрузке операторов new/delete. Итак, начнем копать.

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Эта статья посвящена перегрузке операторов. Особое внимание уделено использованию перегруженных операторов в стандартной библиотеке. Это вторая статья из серии, первая, посвященная перегрузке функций и шаблонов, находится здесь. Следующая статья будет посвящена перегрузке операторов управления памятью.