C *

В статье хочу рассказать о проверке проекта Wine такими статическими анализаторами C/C++ кода, как PVS-Studio и Clang Static Analyzer.

Послушайте!
Ведь, если звезды зажигают — значит — это кому-нибудь нужно?

В. В. Маяковский, 1914

Я занимаюсь программированием для встроенных систем, и данную статью решил написать для того, чтобы лучше разобраться с проблемой использования системных вызовов fork() и vfork(). Второй из них часто советуют не использовать, но ясно, что появился он не просто так.

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

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

Кому интересно, прошу под кат.

KolibriOS – миниатюрная операционная система, ядро и большинство программ которой написано на языке ассемблер. Это, конечно же, не означает, что другим языкам программирования путь в KolibriOS закрыт. К примеру, за время эволюции этой операционной системы было несколько попыток разработать инструментарий или адаптировать библиотеки для создания приложений на языке C/C++. В репозитории KolibriOS до сих пор есть работающие примеры, использующие ранние наработки адаптации C/C++ кода, например (root)/programs/games/kosilka или (root)/programs/system/shell, использующие разные подходы и обертки C/Asm.

На текущее время самой перспективной из существующих библиотек, на мой взгляд, является newlib. Она состоит из адаптированной libc, C-оберкой над основными coreAPI функциями и toolchain’а для сборки.

К сожалению, в KolibriOS нативного компилятора C/C++ еще не существует, текущий toolchain предполагает сборку приложений в ОС Windows или Linux.

Данная статья является инструкцией по настройке newlib для ОС Windows.

Аннотация

В статье описывается фреймворк, позволяющий создавать графические кроссплатформенные приложения, написанные на языке Java, но при этом абсолютно не зависящие ни от Oracle JRE, ни от OpenJDK. Основная идеология фреймворка — по возможности снять с разработчика заботы об обеспечении «родного» look and feel для приложения под каждой операционной системой.

Фактически, на выходе вы получите исполняемый файл, опирающийся только на системные API, на котором нигде не будет клейма «написано на Java».

Все компоненты фреймворка имеют либеральные лицензии (BSD либо Apache), что позволяет использовать их в любых (в том числе, коммерческих) разработках.

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

Готовая, собранная версия приложений, демонстрирующих работу фреймворка под всеми платформами, находится здесь.

Всех интересующихся подробностями милости прошу под кат.

 

Если среднестатистического русскоговорящего разработчика микроконтроллерной электроники попросить назвать 3–5 наиболее известных или крупных производителей микроконтроллеров, наиболее вероятно услышать в ответ такие имена как Microchip, Atmel, TI или STM. Кто-то назовет также NXP, Freescale, Samsung или Fujitsu. Но мало кто вспомнит про еще одного производителя, который на постсоветском пространстве почти неизвестен.

 

Речь идет о японской компании Renesas Electronics, которая, между тем, в своих годовых отчетах хвастается вот такой интересной инфографикой...

Сниффер — специальная программа для анализа и перехвата сетевого трафика, передачи данных через интерфейсы
и многого другого. В данном случае мы будем мониторить операции (чтение и запись) с портами ввода-вывода
на примере телефона линейки Siemens SGold и я постараюсь объяснить, как это всё работает.

Как-то так незаметно получилось, что программист, который разрабатывал нам прошивку для микроконтроллера, стал банально не успевать и в некоторые моменты я начинал перехватывать инициативу и самостоятельно браться за исправление ошибок.
Разработка велась в среде IAR, и многие согласятся со мной, что по сравнению с разработкой в QtCreator'е это боль и страдание.
В какой-то момент мы решили, что быстрее нанять нового программиста и вместе с ним заново переписать прошивку контроллера stm32, так, как я к этому моменту уже немного сам смыслил в их программировании и к тому же обнаружил, что QtCreator умеет отладку на голом железе (плагин BareMetal), я решил принять в этом активное участие.
Здесь я хочу поделиться шаблоном проекта для stm32f407 от Terra Electronica и рассказать об особенностях его настройки.

В библиотеке OpenSSL есть довольно любопытная функция с многообещающим именем CRYPTO_memcmp(). Комментарии к ней объясняют, что обычная memcmp() обладает фатальным недостатком – время ее работы зависит не только от размера сравниваемых блоков, но и от их содержимого, а это может помочь атакующему осуществить так называемую атаку по времени.

Аналогичные функции есть в ряде других проектов — поиск по запросу constant time memcmp дает несколько тысяч результатов.

Не будем подвергать сомнению необходимость использования функции CRYPTO_memcmp(), а вместо этого рассмотрим, решает ли она поставленную ей задачу.

Иногда возникает необходимость ускорить вычисления, причем желательно сразу в разы. При этом приходится отказываться от удобных, но медленных инструментов и прибегать к чему-то более низкоуровневому и быстрому. R имеет довольно развитые возможности для работы с динамическими бибиотеками, написанными на С/С++, Fortran или даже Java. Я по привычке предпочитаю С/С++.

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

Не так давно в OpenSSL была обнаружена уязвимость, о которой не говорит только ленивый. Я знаю, что PVS-Studio не способен найти ошибку, которая приводит к этой уязвимости. Поэтому я решил, что нет повода писать какую-либо статью про OpenSSL. В последние дни и так слишком много стало статей на эту тему. Однако, я получил шквал писем с просьбой рассказать, может ли PVS-Studio найти эту ошибку. Я сдался и написал эту статью.

Волею судеб мне довелось разбираться с организацией многозадачности, точнее псевдо-многозадачности, поскольку задачи делят время на одном ядре процессора. Я уже несколько раз встречала на хабре статьи по данной теме, и мне показалось, что данная тема сообществу интересна, поэтому я позволю себе внести свою скромную лепту в освещение данного вопроса.
Сначала я попытаюсь рассказать о типах многозадачности (кооперативной и вытесняющей). Затем перейду к принципам планирования для вытесняющей многозадачности. Рассказ рассчитан скорее на начинающего читателя, который хочет разобраться, как работает многозадачность на уровне ядра ОС. Но поскольку все будет сопровождаться примерами, которые можно скомпилировать, запустить, и с которыми при желании можно поиграться, то, возможно, статья заинтересует и тех, кто уже знаком с теорией, но никогда не пробовал планировщик “на вкус”. Кому лень читать, может сразу перейти к изучению кода, поскольку код примеров будет взят из нашего проекта.
Ну, и многопоточные котики для привлечения внимания.

Когда я писал об ошибке в GnuTLS, я сказал, что это не последняя тяжелая ошибка в стеке TLS, которую мы увидим. Однако, я не ожидал, что всё будет так плачевно.

Ошибка в Heartbleed — это особенно неприятный баг. Она позволяет злоумышленнику читать до 64 Кб памяти, и исследователи в области безопасности говорят:

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

Недавно компания Microsoft сделала подарок всем программистам, которые хотят покопаться в чем-то интересном. Microsoft открыли исходный код MS-DOS v 1.1, v 2.0 и Word for Windows 1.1a. Операционная система MS-DOS написана на ассемблере, и к ней анализатор не применим. А вот Word написан на языке Си. Исходным кодам Word 1.1a почти 25 лет, однако нам кое-как удалось их проверить. Конечно никакой практической ценности в этой проверке нет. Just for fun.

Я временами бываю озадачен, рассматривая ошибки в очередном программном проекте. Многие из этих ошибок живут в проектах годами. Смотришь на сотню ляпов в коде и удивляешься, как программа вообще работает. И ведь как-то работает. Ей даже пользуются. Причем, я говорю не о коде, рисующем покемона в игре. А, например, о математических библиотеках. Да, вы верно догадались. В этой статье пойдет речь о проверке кода математической библиотеки Scilab.

Значительная часть операционной системы КолибриОС (ядро и большинство драйверов и программ) написаны на языке ассемблера. Тем не менее, программы на языках высокого уровня также есть. Сегодня пойдёт речь об одной из них.

До создания программы командной строки Shell у меня уже был опыт написания программ для КолибриОС. В основном, это были игры – Piton, Donkey, порт эмулятора ZX Spectrum, названный мною e80, порты консольных пятнашек и порт виртуального собеседника Eliza. Я развлекался, как мог.

Мы провели эксперимент по проверке библиотеки glibc с помощью PVS-Studio. Цель эксперимента посмотреть, насколько успешно анализатор может проверять Linux-проекты. Пока плохо может. Возникает огромное количество ложных срабатываний из-за использования нестандартных расширений. Однако, всё равно удалось найти кое что интересное.

В данной статье хочу поделиться своим опытом написания linux драйвера для цветного дисплея 320х240 от производителя Newhavendisplays, а именно NHD-5.7-320240WFB-CTXI-T1 под embedded linux. Идея написать статью созрела именно по причине того, что ресурсов по написанию framebufer(FB) драйверов не так уж и много, тем более, на русском языке. Модуль был написан далеко не под самое новое ядро(2.6.30), поэтому допускаю, что в интерфейсах FB много чего поменялось с тех пор. Но, тем не менее, надеюсь, статья будет интересна интересующимся разработкой уровня ядра linux. Не исключаю, что реализацию можно было бы сделать проще и изящней, поэтому комментарии и замечания приветствуются.

Многие люди задаются вопросом: «Можно ли написать программу на Си под KolibriOS?»
Ответ: «Да, можно!», и ниже я расскажу, как это сделать.


Для написания программы, нам понадобятся:

• Компьютер или виртуальная машина с KolibriOS (если у Вас не установлена KolibriOS, её можно скачать с нашего сайта). Напомню, что KolibriOS для работы требует минимум 8MB RAM и Pentium-совместимый CPU.
• Флешка (если Вы пишете код не в самой Колибри).
• Компилятор TCC (Tiny C Compiler). Сборку для Колибри (mini_c_dev) можно скачать на нашем форуме. Тема с обсуждением ktcc (Kolibri TCC) находится здесь: board.kolibrios.org/viewtopic.php?f=45&t=565

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

Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом 'пережитке прошлого' (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.